AFRL-RH- WP-TR-20 1 0-0043 


Strategy  Planning  Visualization  Tool  (SPVT)  for  the  Air 

Operations  Center  (AOC) 

Volume  II:  Information  Operations  (IO)  Planning  Enhancements 


Christopher  Calhoun 
SRA  International,  Inc. 

5000  Springfield  St. 

Dayton  OH  45431 

Donald  Monk 

Collaborative  Interfaces  Branch 
Warfighter  Interface  Division 

DECEMBER  2009 
Final  Report 

Approved  for  public  release;  distribution  is  unlimited. 

See  additional  restrictions  described  on  inside  pages 


AIR  FORCE  RESEARCH  LABORATORY 
711  HUMAN  PERFORMANCE  WING, 
HUMAN  EFFECTIVENESS  DIRECTORATE, 
WRIGHT-PATTERSON  AIR  FORCE  BASE,  OH  45433 
AIR  FORCE  MATERIEL  COMMAND 
UNITED  STATES  AIR  FORCE 


NOTICE  AND  SIGNATURE  PAGE 


Using  Government  drawings,  specifications,  or  other  data  included  in  this  document  for 
any  purpose  other  than  Government  procurement  does  not  in  any  way  obligate  the  U.S.  Government. 
The  fact  that  the  Government  formulated  or  supplied  the  drawings,  specifications,  or  other  data  does 
not  license  the  holder  or  any  other  person  or  corporation; 

or  convey  any  rights  or  permission  to  manufacture,  use,  or  sell  any  patented  invention  that 
may  relate  to  them. 

This  report  was  cleared  for  public  release  by  the  88th  Air  Base  Wing  Public  Affairs  Office  and  is 
available  to  the  general  public,  including  foreign  nationals. 


Qualified  requestors  may  obtain  copies  of  this  report  from  the  Defense  Technical  Infonnation  Center 
(DTIC)  (http://www.dtic.mil). 

AFRL-RH-WP-TR-20 10-0043  HAS  BEEN  REVIEWED  AND  IS  APPROVED  FOR  PUBLICATION  IN 
ACCORDANCE  WITH  ASSIGNED  DISTRIBUTION  STATEMENT. 


//signed// 

Donald  Monk 
Program  Manager 
Collaborative  Interface  Branch 

//signed// 

Michael  A.  Stropki 
Warfighter  Interface  Division 
Human  Effectiveness  Directorate 
71  lHuman  Performance  Wing 


//signed// 

William  E.  Russell 

Chief,  Collaborative  Interface  Branch 
Warfighter  Interface  Division 


This  report  is  published  in  the  interest  of  scientific  and  technical  information  exchange,  and  its  publication 
does  not  constitute  the  Government’s  approval  or  disapproval  of  its  ideas  or  findings. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  data  sources, 

gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection 

of  information,  including  suggestions  for  reducing  this  burden  to  Washington  Headquarters  Service,  Directorate  for  Information  Operations  and  Reports, 

1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget, 

Paperwork  Reduction  Project  (0704-0188)  Washington,  DC  20503. 

PLEASE  DO  NOT  RETURN  YOUR  FORM  TO  THE  ABOVE  ADDRESS. 


1.  REPORT  DATE  (DD-MM-YYYY) 

31-12-2009 


2.  REPORT  TYPE 

Final 


3.  DATES  COVERED  (From  -  To) 

16  Jul  2004  -  31  Dec  2009 


4.  TITLE  AND  SUBTITLE 

Strategy  Planning  Visualization  Tool  (SPVT)  for  the  Air  Operations 
Center  (AOC)  Volume  II:  Information  Operations  (10)  Planning 
Enhancements 


5a.  CONTRACT  NUMBER 

FA8650-04-C-6537 


5b.  GRANT  NUMBER 


6.  AUTHOR(S) 

Christopher  Calhoun* 
Donald  Monk** 


5c.  PROGRAM  ELEMENT  NUMBER 

6323 IF 


5d.  PROJECT  NUMBER 

2830 


5e.  TASK  NUMBER 

30 


5f.  WORK  UNIT  NUMBER 

28303012 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

SRA  International,  Inc.* 

5000  Springfield  St. 

Dayton  OH  45431 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 


10.  SPONSOR/MONITOR'S  ACRONYM(S) 

711  HPW/RHCP 


11.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 

AFRL-RH-WP-TR-201 0-0043 


9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

Air  Force  Materiel  Command 
Air  Force  Research  Laboratory 
711th  Human  Performance  Wing 
Human  Effectiveness  Directorate 
Warfighter  Interface  Division 
Collaborative  Interfaces  Branch 
Wright  Patterson  AFB  OH  45433-7022 


12.  DISTRIBUTION  AVAILABILITY  STATEMENT 

Approved  for  Public  Release;  Distribution  is  Unlimited. 


13.  SUPPLEMENTARY  NOTES 

88ABW  PA  Cleared  03/03/2010,  88ABW-201 0-1742  &  88ABW-2010-1733.  Volume  II  of  28303012  Dec  2009  Vol  I  Report 


14.  ABSTRACT 

The  purpose  of  this  program  is  to  transition  innovative  work  support  within  the  AOC.  The  idea  is  to  allow 
decisions  to  be  made  and  plans  to  be  formulated  more  quickly  by  providing  users  with  intuitive,  high-level 
visualizations  of  mission  effects,  interrelationships  and  mechanisms.  The  end  result  will  be  improved  planning 
and  assessment  within  the  air  tasking  order  (ATO)  cycle. 


15.  SUBJECT  TERMS 

AOC,  Strategy,  Planning,  JAST,  COA  Sketch,  IOPC-X,  Collaboration,  LiveSpaces,  SPVT 


16.  SECURITY  CLASSIFICATION  OF: 
Unclassified 

17.  LIMITATION  OF 
ABSTRACT 

18.  NUMBER 

OF  PAGES 

19a.  NAME  OF  RESPONSIBLE  PERSON 

Donald  Monk 

a.  REPORT 

U 

b.  ABSTRACT 

U 

c.  THIS  PAGE 

U 

SAR 

184 

19b.  TELEPONE  NUMBER  ( Include  area  code) 

937-255-8814 

This  page  blank  intentionally. 


ii 


TABLE  OF  CONTENTS 


PREFACE . v 

ACKNOWLEDGMENTS . v 

1.0  SUMMARY . 1 

2.0  INTRODUCTION . 2 

3.0  METHODS,  ASSUMPTIONS,  AND  PROCEEDINGS . 4 

3.1  GLOBAL  EFFECTS  MANAGEMENT  SYNCHRONIZATION . 4 

3.2  JAOP  AOD  STATUS  TOOL  (JAST) . 7 

3.3TENEO . 10 

3.4  INFORMATION  OPERATIONS  PLANNING  CAPABILITY  -  EXPERIMENT . 11 

3.4.1  IOPC-X  ARCHITECTURE  OVERVIEW . 13 

4.0  RESULTS  AND  DISCUSSION . 15 

4.1  GLOBAL  EFFECTS  MANAGEMENT  SYNCHRONIZATION . 15 

4.2  JAOP  AOD  STATUS  TOOL  (JAST) . 15 

4.3TENEO . 15 

4.4  INFORMATION  OPERATIONS  PLANNING  CAPABILITY  -  EXPERIMENT . 16 

5.0  SUMMARY . 17 

6.0  BIBLIOGRAPHY . 19 

7.0  ACRONYMS . 26 

Appendix  ll-A  -  GEM-S  10  Assessment  Visualization  Design . A-l 

Appendix  ll-B  -  Teneo  Analysis  Report . B-l 

Appendix  ll-C  -  Teneo  Software  Product  Specification . C-l 

Appendix  ll-D  -  IOPCX  Report . D-l 

iii 


LIST  OF  FIGURES 


Figure  1  GEM-S  Operations,  Activities  and  Actions  (OAA)  View . 5 

Figure  2  GEM-S  Lines  of  Effect  (LOE)  View . 6 

Figure  3  GEM-S  PEL  Assessment  view . 7 

Figure  4  JAST  Implementation  in  the  IWPC  CPT  Module . 9 

Figure  5  IOPC-X  Operational  Use  Case . 11 

Figure  6  IOPC-X  Architecture  Components  (Migration  to  NCES) . 13 


IV 


PREFACE 


The  Strategy  Planning  Visualization  Tool  (SPVT)  project  was  performed  under  the  direction  of 
Mr.  Donald  Monk  of  the  Air  Force  Research  Laboratory’s  71 1th  Human  Perfonnance  Wing 
Human  Effectiveness  Directorate  (711  HPW/RHCP).  The  effort  was  accomplished  under 
Contract  Number  FA8650-04-C-6537,  Human  Effectiveness  in  the  Air  &  Space  Operations 
Center  (AOC). 
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1.0  SUMMARY 


The  Air  Force  Research  Laboratory’s  (AFRL)  71 1th  Human  Performance  Wing  Human 
Effectiveness  Directorate  (711  HPW/RHCP)  created  the  Human  Effectiveness  in  the  Air  & 

Space  Operations  Center  (HE  in  the  AOC)  program  to  address  warfighter  work  challenges 
experienced  in  the  AOC  Strategy  Division  (SD).  The  research  goal  was  to  develop  a  thorough 
understanding  of  warfighter  information  and  decision  requirements  within  the  SD  and  to 
organizations  within  and  beyond  the  AOC  in  order  to  better  support  warfighter  decision  making, 
affordances  and  interactions. 

Phase  I  of  HE  in  the  AOC  was  conducted  by  ManTech  Aegis  and  involved  a  decision- focused 
analysis  of  AOC  SD  personnel.  The  resulting  AOC  Cognitive  Work  Requirements  product 
served  as  a  jumpstart  for  formalizing  user  information  and  decision  requirements.  Phase  II  of  HE 
in  the  AOC  consisted  of  parallel  efforts.  One  effort,  Strategy  Planning  Visualization  Tool 
(SPVT),  was  tasked  with  bringing  decision-centered  visualization  support  to  the  Strategy 
Division  Strategy  Planning  Team  (SPT),  while  the  parallel  effort,  Operational  Effects 
Assessment  Visualization  Tool  (OEAVT),  was  tasked  with  bringing  decision-centered 
visualization  support  to  the  Strategy  Division  Operational  Assessment  Team  (OAT).  OEAVT 
was  performed  by  Science  Applications  International  Corporation  (SAIC)  under  a  separate 
contract. 

SPVT  extended  the  information  contained  in  the  AOC  SD  Phase  I  Cognitive  Task  Analysis 
(CTA)  by  conducting  analyses  and  performing  additional  interviews  with  warfighters.  The 
interaction  with  warfighters  was  used  to  ensure  the  team  had  a  solid  understanding  of  the  CTA, 
to  further  develop  upon  knowledge  of  work  in  the  AOC  SD  and  to  refine  concepts  and 
prototypes.  The  effort  yielded  an  extensive  body  of  knowledge  for  the  AOC  SD  and  resulted  in 
two  prototypes,  transitioning  into  Air  Force  programs  of  record. 
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2.0  INTRODUCTION 


The  primary  dimensions  addressed  under  SPVT’s  decision-centered  analysis  in  the  AOC  SD 
included  the  following: 

•  How  decisions  are  made  in  perfonning  work 

•  How  work  products  are  developed 

•  How  work  is  managed 

•  The  types  of  collaborations  and  interactions  that  are  necessary 

This  knowledge  came  in  part  from  the  Phase  I  AOC  Cognitive  Work  Requirements  which  were 
used  as  a  basis  for  the  cognitive  and  collaboration  work  requirements  for  the  work-centered 
support  visualization  efforts  described  herein. 

Products  from  SPVT  were  designed  to  operate  with  the  related  and  envisioned  information, 
applications,  systems,  and  infrastructure  planned  to  be  delivered  with  the  AOC  Block  10.2  and 
Joint  capabilities,  such  as: 

•  Information  Warfare  Planning  Capability  (IWPC) 

•  Information  Operations  Planning  Capability  -  Joint  (IOPC-J) 

•  Virtual  Integrated  Support  for  the  Information  Operations  Environment  (VisIOn) 

•  Global  Operations  Center  Collaborative  Environment  (GOC-CE) 

•  Theater  Battle  Management  Core  Systems  (TBMCS)/Theater  Battle  Operations  Net¬ 
centric  Environment  (TBONE) 

•  Modernized  Integrated  Database  (MIDB) 

•  Joint  Targeting  Tool  (JTT) 

SPVT  was  comprised  of  several  tasks.  The  initial  sequence  of  tasks  followed  a  human-centered 
systems  engineering  process  from  user  requirements  to  system  concept  and  definition  through 
system  prototype  and  evaluation.  Volume  I  of  this  series  describes  the  entirety  of  the  SPVT  tasks 
in  order  of  their  SPVT  evolution.  Including: 

>  Section  3.1  User  Information  and  Decision  Requirements 

>  Section  3.2  Common  Effects  Picture  (CEP) 

>  Section  3.3  Global  Effects  Management  -  Synchronization  (GEM-S) 

>  Section  3.4  Joint  Air  Operations  Plan  (JAOP)  Air  Operations  Directive  (AOD)  Status 

Tool  (JAST) 

>  Section  3.5  COA  Sketch 

>  Section  3.6  TENEO 

>  Section  3.7  Information  Operations  Planning  Capability  -  Experiment  (IOPC-X) 

>  Section  3.8  Collaboration  in  the  AOC  Context 
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Ultimately,  the  combination  of  requirements  elicitation,  concept  generation  and  refinement,  and 
prototype  development  and  evaluation  resulted  in  a  large  body  of  knowledge  for  the  AOC  SD, 
several  conceptual  prototypes,  one  risk  reduction,  one  technology  demonstration  and  two 
technologies  transitioned  to  United  States  Air  Force  (USAF)  and  United  States  Strategic 
Command  (USSTRATCOM)  programs  of  record. 

The  tasks  collectively  provide  a  solid  work-centered  analysis  of  AOC  SD  processes  and 
decisions  with  several  technologies  designed  to  support  the  various  aspects  of  the  analysis. 

Volume  II  aggregates  the  following  10  Planning  Capability  enhancements  portions  of  SPVT: 

>  Global  Effects  Management  -  Synchronization  (GEM-S) 

>  Joint  Air  Operations  Plan  (JAOP)  Air  Operations  Directive  (AOD)  Status  Tool  (JAST) 

>  TENEO 

>  Information  Operations  Planning  Capability  -  Experiment  (IOPC-X) 
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3.0  METHODS,  ASSUMPTIONS,  AND  PROCEEDINGS 

3.1  GLOBAL  EFFECTS  MANAGEMENT  SYNCHRONIZATION 

The  Joint  Information  Operations  Warfare  Command  (JIOWC)  was  interested  in  exploring 
visualization  concepts  for  an  effects  management  concept  termed  GEM-S.  Initial  concepts  were 
drawn  from  the  Common  Effects  Picture  (CEP)  and  presented  to  the  JIOWC  in  February  2006  as 
a  concept  supporting  the  GEM-S.  Subsequent  design  iterations  for  the  GEM-S  prototype  evolved 
over  several  months  based  on  close  interaction  with  operational  users  and  stakeholders  from  the 
JIOWC.  The  following  paragraphs  describe  the  features  GEM-S  is  intended  to  support.  The  spirit 
of  these  design  features  carry  through  most  aspects  of  SPVT  and  thus  are  described  in  detail 
through  this  section. 

GEM-S  is  a  planning,  assessment  and  campaign  monitoring  capability  designed  to  operate  as  a 
thin  client  over  a  service  oriented  architecture.  It  provides  a  collaborative  environment  for  users 
operating  at  multiple  levels  of  command  and  across  multiple  communities  of  interest.  GEM-S 
provides  support  for  kinetic  and  non-kinetic  operations,  and  includes  unique  capabilities  which 
enable  users  to  create  and  share  user-defined  displays,  develop  and  modify  plans  from  geospatial 
and  temporal  perspectives,  and  create  and  assess  lines  of  effect.  Innovative  views  also  provide 
tailored  campaign  situational  awareness  for  planners,  analysts  and  commanders.  The  primary 
visualization  and  information  components  unique  to  GEM-S  include  Operations,  Activities  & 
Actions  (OAA),  Lines  of  Effects  (LOE),  10  Assessment  and  Information  Ticker  views  and  are 
best  described  in  the  following  operational  context. 

Once  an  operation  is  underway,  operations  assessors  begin  performing  assessments  at  all  levels 
of  the  campaign.  By  opening  each  plan  element  and  associated  Measure  of  Effectiveness 
(MOEs),  planners  and  assessment  analysts  document  the  current  plan  element  state,  assessment 
trend,  and  assessed  effect  status.  Selecting  an  assessment  status  presents  the  user  with  two 
measurements:  Magnitude  Score  and  Direction  Score.  The  effect  Magnitude  refers  to  the  “mass” 
of  the  effect  achieved  when  compared  to  the  desired  amount.  The  effect  Direction  refers  to  the 
positive  or  negative  achievement  of  the  desired  effect. 

Campaign  situational  awareness  is  afforded  through  several  innovative  views.  The  OAA  view 
displays  an  array  of  information  about  plan  contributions  and  dependencies  as  well  as  current 
status  and  trend  information  (see  Figure  1).  Each  of  the  strategic  prioritized  effects  is  displayed 
at  the  top  of  the  screen.  The  colored  circles  to  the  left  indicate  the  current  state  of  each  plan 
element.  A  green  circle  indicates  operations  supporting  this  effect  are  currently  being  executed, 
yellow  indicates  operations  are  planned  but  not  yet  in  progress,  and  red  indicates  the  supporting 
operations  have  yet  to  be  planned.  The  colored  triangles  next  to  the  circles  indicate  the  current 
status  and  trend  of  the  plan  element.  An  upward  pointing  triangle  indicates  an  improvement 
trend,  a  downward  a  worsening  trend  and  to  the  side  indicates  no  change.  The  color  within  the 
triangle  indicates  the  current  assessment  of  that  effect,  with  gradients  of  red,  yellow  and  green 
indicating  various  degrees  of  positive  or  negative  effect.  This  same  methodology  is  repeated  for 
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the  other  levels  of  command.  Note  the  triangles  in  the  center  matrix  also  indicate  which 
Prioritized  Effects  List  (PEL)  effects  they  are  supporting. 


Figure  1  GEM-S  Operations,  Activities  and  Actions  (OAA)  View 

The  LOE  view  (see  Figure  2)  allows  the  planners  to  establish  supporting  relationships  that  show 
how  each  lower  level  effect,  objective  or  task  contributes  to  the  desired  effects  at  the  higher 
level.  The  LOE  view  enables  one  to  display  these  often  complex  contributions  and  dependencies. 
The  same  four  levels  of  command  within  the  Synchronization  View  are  represented  here.  Once 
these  relationships  have  been  established  joint  planners  may  apply  weighting  factors  to 
determine  the  contribution  of  each  supporting  effect.  This  weighting  will  play  a  significant  role 
during  the  ops  assessment  process  by  dictating  how  much  each  individual  lower  level  assessment 
is  able  to  influence  the  success  or  failure  of  higher-level  effects. 

Upon  selecting  the  “Lines  of  Effect”  check  box,  these  relationships  are  displayed,  linking  each 
lower  level  effect  or  objective  to  the  high  level  effect  to  which  it  contributes.  Note  also  that  the 
varied  line  thickness  between  the  elements  represents  the  weighting  established  earlier  in  the 
planning  process.  A  user  who  wishes  to  view  a  single  line  of  effect  can  simply  go  to  the  fly-over 
view  at  the  top  left  and  mouse  over  each  plan  level  to  select  the  specific  effect  of  interest.  Once 
the  desired  element  is  selected,  only  the  plan  elements  to  which  that  effect  depends  or  contributes 
are  displayed.  This  function  may  be  perfonned  at  any  plan  level  of  the  campaign  hierarchy.  Real 
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time  information  updates  are  capable  through  the  Information  Ticker  (scrolling  text)  at  the 
bottom,  center  of  the  view. 


Figure  2  GEM-S  Lines  of  Effect  (LOE)  View 

The  view  which  completes  GEM-S  is  the  PEL  Assessment  (see  Figure  3).  This  view  is  intended 
to  show  a  top  level  status  of  the  entire  campaign  by  displaying  the  current  assessed  status  of 
every  desired  effect  in  the  campaign. . .  at  each  level  of  command.  The  PEL  Assessment 
approach  provides  a  means  for  commanders  to  obtain  immediate  high-level  awareness  of  the 
success  level  for  each  desired  effect.  At  each  selected  campaign  level,  diamond  shapes  represent 
each  effect  present.  Each  effect  consists  of  two  values:  Effect  Magnitude  and  Effect  Direction. 
The  PEL  Assessment  view  captures  both  values  on  orthogonal  axes. 

The  vertical  axis  represents  the  magnitude  score  while  the  horizontal  axis  represents  the  direction 
score.  Note  the  exponential  values  at  the  top  for  the  “viral”  magnitude  score  previously 
discussed.  Each  of  the  effects  is  plotted  on  this  view  using  the  scores  found  on  the  status  tab  of 
each  effect  measure.  Commanders  and  other  decision  makers  are  quickly  able  to  see  which 
effects  are  on  track  and  which  require  further  attention. 
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Figure  3  GEM-S  PEL  Assessment  view 


Appendix  II-A  contains  detailed  theoretical  and  operational  descriptions  of  the  10  Assessment 
view  (developed  by  SAIC  under  subcontract  to  SRA). 


3.2  JAOP  AOD  STATUS  TOOL  (JAST) 

JAST  was  the  product  of  a  need  to  complete  a  key  feedback  path  from  Combat  Operations 
Division  to  the  Strategy  Division.  The  Planning  and  Execution  Status  Bar,  as  described  in  the 
IWPC  CPT  Software  User’s  Manual  (SUM)  supports  the  planning  process  by  providing  useful 
combat  planning  and  execution  status  data  correlated  to  a  published  Joint  Air  Operations  Plans 
(JAOP)  and  the  daily  Air  Operations  Directives  (AOD).  The  SD  produces  the  AOD  which  is 
used  to  develop  the  daily  ATO.  Often,  information  regarding  whether  a  mission  on  the  current 
ATO  is  1)  scheduled,  and  2)  executed,  is  unknown  through  SD’s  next  iteration  of  the  AOD.  The 
missing  infonnation  requires  the  SD  to  re-plan  a  mission  or  missions  whose  execution  status  is 
unknown  in  order  to  ensure  the  tactical  goal  (effect)  is  achieved.  The  opportunity  to  complete 
this  feedback  path  was  realized  with  the  inception  of  TBONE. 
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The  design  of  IWPC  version  4.2b  called  for  TBONE  to  be  (1)  a  receiver  of  the  JAOP  and 
AODs  developed  using  IWPC  and  (2)  a  source  of  plan  status  data  to  include  publishing  the  plan 
and  tracking  status  for  plan  elements  as  they  move  through  targeting,  allocation,  execution 
and  assessment.  JAST  was  the  interface  to  bring  the  TBONE  combat  operations  data  back  into 
the  strategy  planning  world  of  IWPC.  The  IWPC  CPT  requirements  in  Table  1  aligned  with  the 
JAST  requirements  analysis. 


Table  1.  JAST  Planning  and  Execution  Status  Requirements 


Requirement  ID 

Description 

CPT-PE-0001 

The  application  shall  provide  the  user  the  capability  to  track  the 
status  of  Air  Tasking  Orders  (ATO)  planned  and  executed  for  each 
Air  Operations  Directive  (AOD)  or  Joint  Air  Operations  Plan 
(JAOP). 

CPT-PE-0002 

The  application  shall  provide  the  user  with  the  capability  to  load 
planning  and  execution  status  associated  with  an  AOD. 

CPT-PE-0003 

The  application  shall  provide  the  user  with  the  capability  to  request 
updates  to  planning  and  execution  assessment  data 

CPT-PE-0004 

The  application  shall  provide  the  user  with  the  capability  to  view 
planning  and  execution  status  data  for  each  effect 

CPT-PE-0005 

The  application  shall  automatically  provide  the  user  with  the  ability 
of  keeping  track  of  what  planning  and  execution  status  data  has 
been  viewed  and  unviewed  for  each  effect 

CPT-PE-0006 

The  application  shall  provide  the  user  with  the  capability  of  copying 
planning  and  execution  status  data 

CPT-PE-0007 

The  application  shall  provide  the  user  with  the  capability  to  clear 
out  the  tracked  unviewed  planning  and  execution  status  for  each  and 
all  effects. 

The  IWPC  Execution  Status  and  Assessment  data  interfaces  leverage  the  TBONE  Services  and 
data  model.  The  services  and  supporting  Java  2  Platform  Enterprise  Edition  (J2EE)  components 
for  this  component  of  the  IWPC  interface  to  TBONE  is  provided  through  JAST. 

JAST  provides  the  following  capabilities  back  to  IWPC: 

•  JAOP/AOD  Element  Timing 

•  JAOP/AOD  Associated  Target  Status 

•  JAOP/AOD  Decision  Point  Status 

•  JAOP/AOD  Mission  Status 
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These  capabilities  are  shown  in  Figure  1,  where  each  tabbed  section  contained  detailed 
information  on  Timing,  Targets,  Decision  Points  and  Missions.  The  data  handled  by  JAST 
provided  interesting  user  interaction  design,  in  that  JAST  was  intended  to  provide  “updated” 
information.  A  user  interface,  itself,  is  unaware  whether  a  user  has  processed  new  information. 
Therefore,  users  were  required  to  acknowledge  (interact  with  JAST)  when  new  information  was 
presented.  One  example  is  shown  at  the  bottom  of  Figure  1,  where  light  blue  backgrounds  on 
icons  represents  an  information  update  is  available. 
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Figure  4  JAST  implementation  in  the  IWPC  CPT  Module 


JAST  is  designed  as  a  Service  Oriented  Architecture  (SOA).  JAST  complies  with  the  J2EE  1.4 
specification  and  thus  is  scalable  and  secure.  Termination  of  the  TBONE  program,  however,  just 
prior  to  IWPC  deployment  meant  JAST  had  to  be  disabled  within  IWPC  4.2,  i.e.  no  data  feed 
existed  to  populate  JAST.  To  support  JAST  integration  with  IWPC,  the  following  items  were 
delivered  initially  in  October  of  2005  with  software  updates  (based  on  changes  to  the  IWPC 
Software  Developer  Toolkit,  SDK)  as  required  through  December  2006. 

•  JAST  IWPC  Client  Software 

•  JAST  Software  and  Subsequent  Updates 
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•  Esync/Collaborative  Planning  Tool  (CPT)  Software  Users  Manual  (JAST  enhanced) 

•  JAST  Code  Interface  Control  Document  (ICD)  Update 

JAST  enhancements  were  included  in  the  CPT  SUM  (Sections  5.3.8  -  5.3.10.8)  and  eSync  SUM 
(Sections  5. 3. 3. 8  -  5.3.3.10.10)  and  are  published  in  separate  reports.  Each  SUM  was  modified 
to  account  for  inclusion  of  JAST-related  information  within  IWPC  (Note:  these  SUMs  were 
provided  to  the  IWPC  prime  contractor  as  examples  of  where  JAST  reference  material  best  fit, 
however,  additional  technical  editing  was  conducted  by  the  prime  and  thus  these  documents  do 
not  represent  the  SUMs  delivered  with  IWPC  v  4.2e).  The  SUMs  provide  an  excellent  detailed, 
functional  overview  of  JAST  capabilities  within  the  respective  IWPC  capability  module. 

3.3  TENEO 

The  ESC  ISRSG/KIS  and  JIOC  teams  wanted  to  explore  migrating  code  from  an  in-house 
project  to  support  the  maturing  Infonnation  Operations  (10)  Planning  Capabilities  programs, 
IWPC  and  Infonnation  Operations  Navigator  (ION).  These  programs  were  being  installed  at 
various  COCOM  locations  and  specific  areas  of  common  capability  between  current  Air  Force 
and  future  COCOM  needs  were  identified.  The  common  capabilities  included  Intelligence 
Preparation  of  the  Battlespace  (IPB);  10  Strategy  and  Candidate  10  Campaign  Targets 
(Strategy/Targets);  10  Mission  Planning  (10  Missions);  and  Mission  Execution  Monitoring  and 
Assessment  (Assessment). 

The  purpose  of  the  code  migration  was  to  leverage  work  already  perfonned  in  the  area  of 
visualizations  of  Air  Operations  in  support  of  Strategic  Planning  to  further  the  10  Planning 
Capabilities  program.  The  candidate  software  provided  the  following  functionality  in  support  of 
Strategy  Planning  needs: 

•  Data  import  and  filtering  (e.g.  ATO,  intelligence  data,  etc) 

•  Data  display  on  user-selected  map  backgrounds 

•  User-selected  layering  of  the  capability  displays  (i.e.  ability  to  de-clutter) 

•  Visualization  of  notional  operational  effects  of  employing  capabilities  against  specific 
targets,  shown  in  a  time-ordered  sequence  with  playback  (e.g.  nodes  affected  and  when) 

•  Visualization  of  temporal  and  spatial  integration  of  capabilities  into  Operation  Plan 
(OPLAN)  “What  if’  analysis  by  changing  some  data  variables  and  producing  different 
display  results 

•  On-line  help  files,  some  with  capability  specifications  or  OPLAN  references 

The  following  features  were  incorporated  into  the  Teneo  prototype:  1)  launch  Teneo  from  the 
IWPC  main  menu,  2)  allow  the  user  to  view  targets  from  IWPC  through  a  special  layer  inside 
Teneo,  3)  pass  messages  from  IWPC  via  a  rudimentary  publish-subscribe  (“pub-sub”) 
framework  using  web  services,  4)  retrieve  target  data  via  a  web  service  interface  from  IWPC  and 
MIDB  based  on  a  user-defined  geographic  area  of  interest,  5)  retrieve  ATOs  via  a  web  service 
interface  developed  from  a  .NET  adapter  for  TBONE,  and  6)  repaired  the  existing  United  States 
Message  Traffic  Fonnat  (USMTF)  parser  to  expect  any  number.  Finally,  the  IWPC  architecture 
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(Teneo  enhanced)  was  evaluated  to  understand  the  effectiveness  of  an  integration  effort. 
Modifications  to  the  existing  architecture  were  proposed  to  improve,  for  example,  web  services. 

The  purpose  was  to  evaluate  the  client  software  and  the  architecture  as  a  whole.  The  technical 
(Analysis)  Report  and  Software  Product  Specification  were  delivered  in  June  of  2007  and  are 
available  separately  in  Appendix  II-B  and  II-C,  respectively. 


3.4  INFORMATION  OPERATIONS  PLANNING  CAPABILITY  -  EXPERIMENT 

IOPC-X  was  a  risk  reduction  capability  to  develop  a  modem  SOA-based  architecture  for  IWPC 
and  to  refine  future  technical  and  operational  requirements.  Primary  operational  and  technical 
direction  was  provided  by  the  Joint  Forces  Command  (JFCOM)  Engineering  Staff  Section  (J7) 
VisIOn  Technical  Integrative  Product  Team.  The  IOPC-X  environment  enabled  demonstrating 
COA  Sketch  as  a  plug-in  capability  to  the  SOA-based  IWPC.  The  resulting  IOPC-X  prototype 
provided  the  following: 

■  A  software  Net-Centric  infrastructure  prototype  enabling  integration  of  new  capability 
modules  (CM) 

■  A  pluggable  infrastructure  of  core  IWPC  tools  and  10  analysis  capabilities 

■  Alignment  with  the  Net-Enabled  Command  Capability  (NECC)  and  Net-Centric  Core 
Enterprise  Services  (NCES)  standards  and  capabilities 

A  use  case  diagram  is  provided  in  Figure  4.  A  detailed  description  of  this  task  is  provided  in 
Appendix  II-D. 


11 

Data  subject  to  restriction  on  cover  and  Notice  page 
Approved  for  public  release;  Distribution  is  unlimited 


7|  Current  IWPC 
user  Interacts 
IOPC  Data 


8|  3rd  Party 
Developed 
Application 
Interfaces  to  IOPC 
Data 


3)  User  receives  search  results 


Search  Results  with 
Information  Source  and  Capability  Module 


4 1  User  selects  CM 
Presentation  Service 


System 

Human  Computer  Interface 


IOPC-X  Infrastructure 


Operational  User 
(via  3rd  Party 
Application) 


6|  IOPC-X  Thin  Client 
allows  Remote  or 
Disadvantaged 
user  to  access  the 
plan 


5)  IOPC-X  Client  provides 
Developed  plug-in 
Application 


Remote  Operational  User 
(via  Thin  Client  Application) 


Eclipse  OSGi  Plug-in 
HCI 


Operational  User 
(Planner) 


Figure  5  IOPC-X  Operational  Use  Case 


The  IOPC-X  SDK  is  published  as  a  separate  report  and  contains  an  overview  of  the  IOPC-X 
Architecture  and  summarizes  the  Net-Centric  Standards  that  were  used.  The  standards  for  IOPC- 
X  are  registered  with  DoD  Information  Technology  Standards  Registry  (DISR)  and  follow  the 
guidance  provided  in  the  Net-Centric  Operational  Warfare  Reference  Model  (NCOW-RM). 
Reasoning  and  correlation  of  the  standards  followed  are  detailed  in  the  appropriate  sections  of 


the  SDK. 


The  SDK  includes  a  discussion  of  the  Plug-in  Infrastructure  based  on  the  Eclipse  Rich  Client 
Platform  (RCP)  and  Registration  of  the  plug-ins  for  discovery  of  the  CMs.  The  SDK  moves  from 

TM  TM 

the  client  side  to  discussion  of  the  J2EE  Enterprise  JavaBeans  (EJB  )  3.0  compliant  data 
access  tier  and  its  use  of  the  JENA  library  set  and  Oracle  database  for  Ontological  persistence  of 
information.  With  understanding  of  the  data  access  tier,  the  SDK  returns  to  discussion  of  the 
middle  tier  to  cover  the  IOPC-X  Web  Services  which  act  as  a  Facade  onto  the  J2EE  session 
bean  discussed  in  the  data  access  tier  section. 


Security  considerations  are  discussed  in  their  appropriate  sections.  Throughout  the  SDK, 
Sequence  diagrams  are  provided  to  visually  reflect  uses  of  the  IOPC-X  interfaces  being 
discussed.  IOPC-X  specific,  as  well  as  open  source  code,  examples  and  tutorials  have  been 
provided  or  referenced  to  ensure  complete  understanding  of  how  to  properly  build  IOPC-X 
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compliant  components.  The  supporting  Unified  Modeling  Language  (UML)  design  diagrams  and 
Javadocs  have  been  provided  as  sections  to  the  SDK. 

3.4.1  IOPC-X  ARCHITECTURE  OVERVIEW 


Figure  5  illustrates  the  IOPC-X  architecture  components.  The  IOPC-X  architecture  is  a  fully  Net- 

TM  TM 

Centric  compliant  design  which  leverages  a  J2EE  EJB  3.0  compliant  infrastructure  for  ease  in 
Authentication,  Authorization  and  Scalability.  The  J2EE  session  beans  are  also  exposed  via 


Web  Service  interfaces.  The  ontology-based  backend  leverages  the  JENA  library  set  in  order  to 

address  the  requirements  of  the  Net-Centric  Data  Strategy. 
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Figure  6  IOPC-X  Architecture  Components  (Migration  to  NCES) 


The  client  architecture  supports  an  evolutionary  development  path  and  re-use  of  existing  Java™ 
and  .Net  developed  “Fat  Clients.”  The  IOPC-X  design  includes  an  Open  Services  Gateway 
Initiative  (OSGi)  compliant  plug-in  infrastructure  based  upon  the  Eclipse  RCP. 


IOPC-X  client  components  included  the  following: 
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IOPC-X  RCP  Workbench  which  acts  as  a  ‘baseline’  IOPC-X  installation.  All  client  plug¬ 
ins  will  use  the  workbench  as  their  target  platform.  The  workbench  initializes  the  main 
client  window,  menus,  and  toolbars,  providing  a  predictable  environment  for  the  plug-ins. 
The  Data  Access  plug-in  provides  a  locally  replicated  copy  of  the  ontology  in  an  effort  to 
reduce  memory  consumption  and  network  traffic.  The  plug-in  has  the  same  interface  as 
the  web  service,  but  references  its  own  ontology  and  prevents  all  plug-ins  from  having  to 
maintain  a  separate  instance  of  the  ontology  and  keep  track  of  updates.  However,  use  of 
this  plug-in  is  not  mandatory  and  a  client  plug-in  could  reference  the  web  service 
interface  directly. 

The  Login  &  Security  plug-in  provides  authentication  routines  and  login  handling  in  the 
workbench.  This  plug-in  provides  the  login  information  to  any  other  plug-ins  that  need  to 
access  it  (such  as  the  Data  Access  plug-in). 

The  Dynamic  update  plug-in  provides  client  updates  transparently.  No  additional 
software  needs  to  be  written  to  allow  dynamic  update  -  this  capability  is  provided  by  the 
workbench  and  the  OSGi  framework. 
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4.0  RESULTS  AND  DISCUSSION 

4.1  GLOBAL  ELLECTS  MANAGEMENT  SYNCHRONIZATION 

GEM-S  resulted  in  several  innovative  visualization  concepts  for  effects  management  on  a  global 
scale.  Some  concepts  were  based  on  earlier  CEP  designs  and  some  concepts  evolved  from 
interaction  with  the  JIOWC  user  community.  The  GEM-S  prototype  was  developed  with  a  fully 
interactive  user  interface,  although  with  no  data  storage  or  handling  capabilities. 

The  prototype  capabilities  were  well  received  and,  conceptually,  the  GEM-S  prototype  provided 
an  infonnative  view  onto  operations  at  a  large  scale.  Of  primary  operational  concern,  however, 
were  the  data  sources  required  to  feed  GEM-S.  A  single  data  source  clearly  was  not  possible 
across  multiple  agencies,  organizations  and  programs,  and,  while  a  suite  of  data  sources  was  a 
more  likely  scenario,  the  challenge  remained  to  access  numerous  stove-piped  systems, 
inconsistent  fonnats  and  manual  records.  Ultimately,  the  data  required  to  support  and  maintain 
GEM-S  was  considered  an  unattainable  task  and  further  development  stopped  as  a  standalone 
capability. 


4.2  JAOP  AOD  STATUS  TOOL  (JAST) 

JAST  was  the  product  of  a  need  to  complete  a  significant  infonnation  feedback  path  from  CO  to 
the  SD  by  providing  useful  combat  planning  and  execution  status  data  correlated  to  a  published 
Joint  Air  Operations  Plans  (JAOP)  and  the  daily  Air  Operations  Directives  (AOD).  Termination 
of  the  TBONE  program,  however,  just  prior  to  IWPC  deployment  meant  JAST  had  to  be 
disabled  in  the  IWPC  v4.2  (i.e.  the  required  data  feed  to  populate  JAST  did  not  exist).  JAST  was 
fully  integrated  with  IWPC  software  and  deployed  to  warfighters,  however,  the  capability  was 
simply  never  “turned  on”  and  thus  users  were  never  made  aware  that  the  capability  exists  should 
appropriate  data  feeds  become  available  in  the  future. 


4.3  TENEO 

Teneo  was  a  prototype  and  was  not  intended  for  production  use.  While  the  concepts  that  Teneo 
presented  were  excellent,  the  implementation  had  some  problems.  Teneo  was  meant  to  be  a 
prototype  and  not  intended  for  release  or  integration.  The  software  was  developed  very  quickly 
for  a  specific  audience  and,  as  such,  made  many  assumptions.  These  assumptions  precluded  any 
error  handling  or  concern  for  the  needs  of  a  generic  user.  Errors  were  generally  handled  by 
application  failure  and  subsequently,  exiting  the  program.  As  a  prototype,  code  comments  were 
neither  present  nor  expected  and  the  provided  documentation  reflected  the  concepts  of  Electronic 
Warfare  (EW),  rather  than  providing  insight  into  the  software  development.  The  evaluation 
resulted  in  the  recommendation  to  completely  redesign  and  rewrite  Teneo. 
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4.4  INFORMATION  OPERATIONS  PLANNING  CAPABILITY  -  EXPERIMENT 


IOPC-X  was  a  risk  reduction  capability  to  develop  a  modem  SOA-based  architecture  for  IWPC 
to  refine  future  technical  and  operational  requirements.  COA  Sketch  and  SMART  were 
integrated  as  capabilities  within  the  IOPC-X  framework.  The  IOPC-X  prototype  was  used  in  the 
Pirate’s  Daggers  Exercise  2008  to  demonstrate  the  SOA  architecture  and  the  plug-in 
infrastructure. 

Determining  the  best  way  ahead  for  COA  Sketch/IOPC-X  capability  framework  requires  more 
research.  An  end-to-end  review  of  COA  Sketch/IOPC-X  is  highly  recommended  prior  to  full- 
scale  design  for  the  potential  next  generation  platform,  COA  Sketch/aXiom.  At  a  minimum  the 
data  model,  and  particularly  the  date  and  constraint  model,  should  be  reviewed  with  the  goal  of 
expressing  queries  and  pattern  matches  concisely.  This  effort  should  produce  a  flatter,  more 
redundant,  class  model  with  fewer  classes  and  less  nesting  of  objects. 

The  COA  Sketch/IOPC-X  Web  Service  Description  Language  (WSDL)  interface  will  need  to  be 
reviewed  along  with  the  data  model.  The  current  design  is  a  general  purpose  Create,  Update, 
Delete  model.  System-level  study  is  needed  to  determine  if  more  business-level  tasks  can  be 
defined  at  the  web  service  layer.  In  addition,  the  serialization  constraints  inherent  in  the  current 
data  model  need  to  be  removed.  Many  object  classes  cannot  currently  be  serialized  as  stand¬ 
alone  objects  -  they  require  additional  document  portions.  This  approach  must  be  redesigned  so 
that  the  data  model  objects  can  be  used  in  a  more  encapsulated  fashion. 

Finally,  the  lack  of  support  for  ontological  data  formats  (SPARQL  and  SPARQL  result-set 
XML)  in  the  client  application  is  a  shortfall.  The  data  interchange  between  some  plug-ins  such  as 
COA  Sketch  and  server  is  problematic.  Pushing  the  responsibility  for  query  execution  and 
processing  to  the  client  tier  goes  against  the  theory  of  N-tiered  architectural  design  and  violates 
the  assumption  of  a  course-grained,  optimistic  system.  Expectations  for  the  capabilities  of  an 
ontological  data  access  client  must  be  recalibrated  and  agreed  upon.  One  might  consider  the 
COA  Sketch  service  the  true  ontological  client  and  the  COA  Sketch  thin  client  merely  a  display 
layer.  In  any  case,  SPARQL  result  sets  are  not  ideal  for  passing  data  in  a  client  /  server  system. 
Other  ontological  technologies  such  as  RDF/XML  may  be  more  suitable,  but  replacing  a  well- 
known  and  understood  technology  like  WSDL  with  RDF/XML  requires  more  research. 


16 

Data  subject  to  restriction  on  cover  and  Notice  page 
Approved  for  public  release;  Distribution  is  unlimited 


5.0  SUMMARY 


SPVT  was  a  multi-year  effort  focused  on  improving  warfighter  effectiveness  in  the  AOC 
Strategy  Planning  context  through  work-centered  understanding  of  warfighter  information  and 
decision  requirements.  The  primary  dimensions  addressed  included:  how  decisions  are  made  in 
the  Strategy  Division  in  perfonning  work;  how  work  products  are  developed;  how  work  is 
managed;  and  the  types  of  collaborations  and  interactions  that  are  necessary. 

SPVT  tasking  followed  a  human-centered,  systems  engineering  process,  beginning  with  defining 
operational  user  infonnation  and  decision  making  requirements  through  a  combination  of 
modeling  work-relevant  documentation  and  interviewing  warfighters  (on  site  with  warfighter  in 
role  and  off  site  with  warfighter  role  playing).  Findings  from  the  User  Requirements  Analysis 
drove  the  next  set  of  activities.  (Note  the  team  continued  to  build  on  the  user  information 
requirements  as  new  documentation  and  warfighter  interviews  became  available.)  Initial 
concepts  focused  on  developing  an  effects-based  dashboard,  Common  Effects  Picture  (CEP), 
suitable  for  the  Commander  to  obtain  a  quick  and  accurate  assessment  of  the  battlespace.  A  key 
characteristic  of  CEP  was  transparency  from  the  highest  level  of  infonnation  aggregation  into  the 
supporting  data,  methods  and  analyses. 

A  logical  extension  of  CEP  was  to  a  joint  service  effects  management  system,  Global  Effects 
Management  -  Synchronization  (GEM-S),  an  envisioned  single  collection  point  for  organizing 
and  deconflicting  multi-service  global  operations.  GEM-S  provided  a  venue  to  explore  interface 
and  visualization  concepts  for  the  many  interactions  among  agencies,  activities  and  effects. 

Following  the  goal  to  support  the  Strategy  Division,  the  next  SPVT  task  focused  on  enhancing 
the  AOC  planning  system  of  record,  IWPC,  by  bringing  near  real-time  ATO  execution 
infonnation  from  Combat  Operations  directly  to  the  Strategy  Division  rather  than  waiting  on 
slow  and  sometimes  incomplete  reports  from  the  Operations  Assessment  Team.  The  JAOP  AOD 
Status  Tool  (JAST)  was  integrated  with  IWPC  4.2.5  eSync/CPT  capability  modules  and 
instantiated  through  a  series  of  basic  visualizations. 

Building  on  supporting  the  Strategy  Planner,  Course  of  Action  Sketch  (CO A  Sketch)  took  a 
previously  text-based,  manual,  single  person  bottlenecked  process  and  transformed  it  to  a 
graphical,  human-supported  automation,  collaborative  technology.  COA  Sketch  provides  a 
human-focused  electronic  work  environment  for  the  warfighter  to  flexibly  and  adaptively 
collaborate  in  JAOP  development.  Strategy  planners  have  the  capability  to  capture  the  plan  as  it 
is  developed.  And  while  simple  in  concept,  COA  Sketch  brought  together  capabilities 
warfighters  most  desired  during  strategy  planning  such  as  Shared  awareness;  Graphics  that  are 
data  aware;  Collaborative  development;  and  Support  for  development  toward  a  team  mental 
model.  COA  Sketch  transition  to  two  separate  programs  provided  the  validation  that  decision- 
centered  visualization  support  to  the  AOC  Strategy  Planner  was  accomplished. 
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While  COA  Sketch  was  an  evolving  technology,  TENEO  was  brought  to  the  SPVT  program  for 
evaluation  as  a  capability  enhancement  to  IWPC.  TENEO  included  several  planning  capabilities 
similar  in  concept  to  COA  Sketch  but  much  less  robust  from  a  software  development 
perspective.  The  impetus  for  the  project  was  to  determine  whether  TENEO  capabilities  were 
mature  enough  to  integrate  with  IWPC.  The  short  answer  was  “no”  and  the  customer,  after 
learning  of  COA  Sketch,  proposed  the  following  opportunity. 

As  COA  Sketch  continued  to  mature,  more  emphasis  was  placed  on  developing  the  underlying 
data  model  and  architecture.  Information  Operations  Planning  Capability  -  Experiment 
(IOPC-X)  was  a  risk  reduction  effort  to  develop  a  net-centric  data  strategy  and  architecture. 
IOPC-X  evolved  to  the  JFCOM  sponsored  VisIOn  program  and  simultaneously  was  soliciting 
capabilities  to  plug  into  the  future  architecture.  COA  Sketch  met  the  desired  operational  strategy 
planning  requirements  and  was  transitioned. 

Maturation  of  COA  Sketch  and  IOPC-X  required  access  to  operationally-relevant,  planning 
mission  data  sources  such  as  MIDB,  JTT  and  FrOB.  The  External  Interfaces  task  explored 
connection  to  these  databases. 

Collaboration  in  the  AO C  Context  focused  on  supporting  the  Strategy  Division  through 
improved  human-machine  and  human-human  information  exchanges.  Specifically,  the  tested 
capability,  LiveSpaces,  supports  Intense  Collaboration  (the  type  often  found  in  Command  and 
Control  environments).  The  final  event  for  SPVT  included  application  of  LiveSpaces  during  the 
TTCP  C3I  TP2  Workshop,  in  which  representatives  from  three  countries  engaged  in 
collaboration  activities. 

The  Human  Effectiveness  in  the  Air  &  Space  Operations  Center  program  addressed  warfighter 
work  challenges  through  decision-centered  visualization  support  to  the  AOC  Strategy  Division. 
The  program  started  with  developing  a  thorough  understanding  of  the  warfighter  infonnation  and 
decision  support  requirements,  individual,  machine  and  team  interactions.  A  strong  initial 
cognitive  work  analysis  set  the  foundation  for  subsequent  program  activities,  a  series  of  decision 
support  visualization  concepts  with  increasing  capability  and  fidelity.  The  effort  sponsored  by 
the  AFRL  711  Human  Perfonnance  Wing/Human  Effectiveness  Directorate  yielded  an  extensive 
body  of  knowledge  for  the  AOC  SD,  numerous  concepts  available  to  other  USAF  and  Joint 
programs,  and  resulted  in  three  transitioned  products,  one  to  the  ESC  IWPC  program,  the 
USSTRATCOM  ISPAN  program,  and  one  to  the  JFCOM  VisIOn  program. 
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7.0  ACRONYMS 


711  HPW/RHCP 

711  Human  Perfonnance  Wing/Human  Engineering  Directorate, 
Warfighter  Interfaces  Division,  Collaborative  Interfaces  Branch 

ACC 

Air  Combat  Command 

AFRL 

Air  Force  Research  Laboratory 

AOC 

Air  &  Space  Operations  Center 

AOD 

Air  Operations  Directive 

ATO 

Air  Tasking  Order 

BOGSAT 

Bunch  of  Old  Guys  Sitting  Around  the  Table 

CEP 

Common  Effects  Picture 

CM 

Capability  Modules 

CO 

Combat  Operations 

COA 

Course  of  Action 

COCOM 

Combatant  Command 

CPT 

Collaborative  Planning  Tool 

CTA 

Cognitive  Task  Analysis 

CWA 

Cognitive  Work  Analysis 

DCO 

Defense  Connect  Online 

DISR 

DoD  Information  Technology  Standards  Registry 

DoD 

Department  of  Defense 

DRDC 

Defence  Research  and  Development  Canada 

DSTO 

Defence  Science  and  Technology  Organisation 

EJB 

Enterprise  JavaBeans 

EW 

Electronic  Warfare 

FrOB 

Friendly  Order  of  Battle 

GCIC 

Global  Cyberspace  Innovation  Center 

GEM-S 

Global  Effects  Management-Synchronization 

GOC-CE 

Global  Operations  Center  Collaborative  Environment 

HE  in  the  AOC 

Human  Engineering  in  the  AOC 

HPW 

Human  Perfonnance  Wing 

ICD 

Interface  Control  Document 

IPB 

Intelligence  Preparation  of  the  Battlespace 

10 

Information  Operations 

ION 

Information  Operations  Navigator 

IOPC-J 

Information  Operations  Planning  Capability  -  Joint 

IOPC-X 

Information  Operations  Planning  Capability  -  Experiment 

ISPAN 

Integrated  Strategic  Planning  &  Analysis  Network 

IWPC 

Information  Warfare  Planning  Capability 

J2EE 

Java  2  Platform  Enterprise  Edition 

JAOP 

Joint  Air  Operations  Plan 

JAST 

JAOP  AOD  Status  Tool 

JFACC 

Joint  Forces  Air  Component  Commander 
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JFCOM 

Joint  Forces  Command 

JIOWC 

Joint  Infonnation  Operations  Warfare  Command 

JTT 

Joint  Targeting  Tool 

KPP 

Key  Performance  Parameter 

LOE 

Lines  of  Effects 

MIDB 

Modernized  Integrated  Database 

MOE 

Measure  of  Effectiveness 

NCES 

Net-Centric  Core  Enterprise  Services 

NCOW-RM 

Net-Centric  Operational  Warfare  Reference  Model 

NECC 

Net-Enabled  Command  Capability 

OAA 

Operations,  Activities  &  Actions 

OAT 

Operational  Assessment  Team 

OEAVT 

Operational  Effects  Assessment  Visualization  Tool 

OPLAN 

Operation  Plan 

OSGi 

Open  Services  Gateway  Initiative 

PEL 

Prioritized  Effects  List 

RCP 

Eclipse  Rich  Client  Platform 

Ret 

Retired 

SAIC 

Science  Applications  International  Corporation 

SD 

Strategy  Division 

SDK 

Software  Development  Toolkit 

SGT 

Strategy  Guidance  Team 

SME 

Subject  Matter  Expert 

SOA 

Service  Oriented  Architecture 

SPO 

System  Program  Office 

SPT 

Strategy  Planning  Team 

SPVT 

Strategy  Planning  Visualization  Tool 

SUM 

Software  User’s  Manual 

TBMCS 

Theater  Battle  Management  Core  Systems 

TBONE 

Theater  Battle  Operations  Net-centric  Environment 

TTCP  C3I  TP2 

The  Technical  Cooperation  Program  Technical  Panel  on  Command 
Infonnation  Interfaces 

UML 

Unified  Modeling  Language 

USAF 

United  States  Air  Force 

USMTF 

United  State  Message  Traffic  Fonnat 

USSTRATCOM 

United  States  Strategic  Command 

VisIOn 

Virtual  Integrated  Support  for  the  Information  Operations  Environment 

VPN 

Virtual  Private  Network 

WAW 

Warfighter  Assessment  Workshop 

WSDL 

Web  Service  Description  Language 
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APPENDIX  II-A  -  GEM-S  IO  ASSESSMENT  VISUALIZATION  DESIGN 


The  following  report  was  submitted  to  SRA  through  a  subcontract  to  SA1C  for  GEM-S  10 
assessment  visualization  concept  development  support. 
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GEM-S  10  Assessment  Visualization  Design  and  Prototype 


1.0  Introduction 


This  report  summarizes  the  activity  performed  in  support  of  the  GEM-S  10 
Assessment  Visualization  effort,  including  evaluation  of  the  Adobe  Flash  prototype 
with  identification  of  shortcomings  and  potential  improvements. 

In  addition  to  the  introduction,  the  report  contains  the  following  main  sections: 

2.0  Background  of  the  effort,  including  summaries  of  the  elicitation 

sessions.  Unclassified  elicitation  slides  and  trip  report  are  contained 
in  Section  6  and  Section  7. 

3.0  10  Assessment  Use  Case  Study,  satisfying  the  deliverable  requirement 

for  defining  use  cases. 

4.0  10  Assessment  Prototype  Functional  Description.  This  section 

provides  an  overview  of  the  basic  features  of  the  prototype 
assessment  visualization,  with  detailed  descriptions  of  the  controls 
and  indicators  contained  in  Section  8  (satisfying  the  requirement  for  a 
functional  description). 

5.0  Identification  of  prototype  tool  shortcomings  and  areas  for 

improvement.  Specific  areas  for  improvement  are  identified  and 
modified  display  concepts  are  illustrated.  These  are  based  on  Subject 
Matter  Expert  (SME)  and  developer  peer  review  of  the  prototype  tool 
using  both  random  and  scenario-driven  data.  The  scenario  used  to 
support  this  evaluation  is  described  in  Section  9  and  Section  10. 

6.0  Assessment  concept  slides.  The  following  10  assessment  concepts 

slides  were  presented  December  19,  2007  elicitation  of  10  planners  at 
the  Joint  Information  Operations  Warfare  Center  (JIOWC). 

7.0  Trip  Report  for  December  19,  2007  Elicitation  at  the  JIOWC.  The 
following  trip  report  applies  to  the  elicitations  of  10  planners 
conducted  regarding  10  assessment,  December  19,  2007  at  the  Joint 
Information  Operations  Warfare  Center. 

8.0  Visual  and  Functional  Specification  of  the  10  Assessment  Prototype.  The 

following  details  the  visual  and  functional  specification  of  the  10 
Assessment  prototype. 
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9.0  Fictional  Scenario  for  Prototype  Assessment  Tool  Evaluation.  The 

following  details  the  fictional  scenario  for  the  prototype  assessment 
tool  evaluation. 

10.0  XML  Plan  File  for  Operation  Healing  Voice  Scenario.  The  following  is 
the  plan  file  for  Operation  Healing  Voice  scenario  in  XML  format. 
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2.0  Background  of  the  effort 


Development  of  the  GEM-S  Assessment  Visualization  Prototype  (the  Assessment 
Tool),  was  a  short-term  effort  to  address  a  lack  of  Influence  Operations  (IFO) 
assessment  visualizations  to  support  broad-ranging,  national-level  10  goals  for  the 
Joint  Information  Operations  Warfare  Center  (JIOWC).  This  effort  originated  at  an 
Air  Force  Research  Laboratory  (AFRL)  workshop  where  SAIC’s  Operational  Effect 
Assessment  Visualization  Technology  (OEAVT)  tools  for  visualizing  the  assessment 
of  effects-based  air  operations  were  demonstrated  and  observed  by  Joint  Forces 
Command  (JFCOM)  personnel. 

An  initial  elicitation  trip  to  the  JIOWC  on  10  October  2007  introduced  the  broad 
scope  of  IFO  activities,  and  the  need  for  visualizing  and  assessing  the  various  IFO 
activities  associated  with  this  plan.  Classified  topics  were  discussed  in  the 
elicitation,  which  are  not  further  described.  A  visualization  called  the  Global  Effects 
Matrix-Synchronization  (GEM-S),  had  been  constructed  using  a  spreadsheet  by  the 
J24  Intelligence  Support/SOCOM  Team.  The  spreadsheet  implementation  of  GEM-S, 
also  known  as  the  "horse  blanket,"  mapped  national  IFO  objectives  to  a  Primary 
Effects  List  (PEL),  and  in  turn  to  an  activity  performed  by  a  U.S.  Government  (DoD, 
State  or  other  agency)  or  non-U. S.  government  activity.  The  status  of  the  activity 
was  color-coded  to  indicate  active,  planned,  or  needed.  In  this  manner,  the  color 
code  cells  of  the  spreadsheet  provided  a  rapid  view  of  who  was  doing/planning 
what  (at  the  level  of  program  title),  versus  the  objectives  of  the  NIP.  A  column 
labeled  "assessment,"  mapped  to  objectives,  was  blank. 

An  unclassified  surrogate  of  the  "horse  blanket"  is  depicted  in  Figure  1,  and 
summarizes  the  basic  elements  of  the  synchronization  matrix  using  the  example  of 
introducing  electric  vehicles  to  the  U.S. 
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Figure  1:  Unclassified  surrogate  for  the  GEM-s  "Horse  Blanket" 
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Based  on  this  initial  elicitation,  SRA  was  tasked  to  adopt  their  COA  Sketch  tool 
technology  to  automating  the  GEM-S,  and  SAIC  was  tasked  with  prototyping 
visualization  techniques  for  IFO  assessment. 

A  second,  unclassified  elicitation  session  was  held  19  December  2007  at  SRA’s  San 
Antonio  facilities,  and  covered  specifically  the  topic  of  IFO  assessment.  SAIC 
presented  a  small  set  of  slides  describing  an  IFO  assessment  concept,  and  received 
constructive  feedback  on  IFO  assessment.  Section  6  contains  the  slides  presented 
by  SAIC,  and  Section  7  includes  the  trip  report  for  that  elicitation  session. 

The  assessment  visualization  concepts  for  IFO  presented  during  the  second 
elicitation  focused  on  characterizing  the  achieved  effect  of  an  IFO  activity  in  terms  of 
perception  of  the  delivered  message  (direction)  and  penetration  of  the  message  in 
the  target  population  (magnitude).  No  attempt  to  plot  achieved  effect  versus 
expended  effort  was  made  due  to  the  difficulty  in  uniformly  quantifying  effort  across 
the  activity  domain  of  the  GEM-S.  Unlike  kinetic  air  operations,  where  effort  is  fairly 
uniformly  measured  in  Desired  Mean  Point  of  Impact  (DMPI)  -  sortie  -  equivalents 
(DSEs),  no  uniform  measure  of  IFO  effort  is  known  to  exist.  [For  an  explanation  of 
DMPIs  and  DSEs  as  applied  to  kinetic  planning  and  assessment,  see  AFTTO  3-3.AOC,  1 
November  2007  FINAL,  section  3. 3. 3. 3). 

A  final,  informal  elicitation  was  conducted  on  21  February  2008  at  the  JIOWC, 
during  SRA’s  installation  of  their  GEM-S/COA  Sketch  prototype.  Classified  topics 
were  discussed  along  with  the  general  nature  of  IFO  assessment.  A  USAF  Lt  Col 
foreign  media  analyst  and  IFO  assessor  confirmed  the  utility  of  the 
direction/magnitude  assessment  paradigm  and  provided  samples  of  typical  raw 
input  provided  to  IFO  assessors  by  commercial  foreign  media  analysts,  highlighting 
the  need  to  refer  to  files  in  addition  to  operator  provided  comments  in  justifying 
assessments.  Additional  discussions  were  conducted  on  10  operations  other  than 
IFO.  Jamming  an  adversary’s  transmitter  is  an  example  of  such  an  operation. 
Currently,  the  results  of  such  operations  are  assessed  on  a  "4-D"  basis:  Disrupt, 

Deny,  Damage,  Destroy;  which  can  be  thought  of  in  terms  of  increasing  duration  and 
degree  of  effect  on  a  target  system.  This  discussion  prompted  the  inclusion  of  what 
we  will  describe,  for  lack  of  a  general  term,  as  an  "active"  10  display,  as  opposed  to 
IFO,  in  the  prototype  assessment  tool. 
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3.0  10  Assessment  Use  Case  Study 


The  Prototype  Assessment  Visualization  Tool  was  designed  to  support  proof-of- 
concept  demonstration  to  users  for  the  purpose  of  refining  and  improving  10 
assessment  displays.  As  such,  it  is  not  designed  as  a  stand-alone  tool,  but  as  a 
visualization  "engine,"  which  relies  on  an  external  system  (COA  Sketch)  for 
Operational  Plan  inputs  and  underlying  database.  The  Use  Cases  (Figure  2) 
presented  here  are  based  on  this  constraint. 


Figure  2:  Use  Case  Diagram 
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Use  Case:  View  Plan  Element  Detail 


Description:  The  10  Assessor  views  the  current  assessment  of  an  element  of  the  Plan  in 
detail. 

Pre-Conditions: 

•  The  10  Assessment  tool  must  be  loaded  with  plan  data. 

Post-Conditions: 

•  SUCCESS  -  The  detailed  assessment  for  the  selected  plan  element  is  displayed. 

•  FAILURE  -  None 

Steps: 

1 .  10  Assessor  scrolls  through  the  plan  tree  view  until  the  desired  plan  element  is  in 
view. 

2.  10  Assessor  may  collapse  or  expand  the  tree  as  needed. 

3.  10  Assessor  clicks  on  the  desired  plan  element. 

<The  detailed  graph  updates  to  display  the  graph  of  the  selected  plan  element’s 
assessment  data.  > 

<The  indicator  list  updates  to  display  the  list  of  the  selected  plan  element’s  indicators 
and  child  plan  elements.  They  are  all  displayed  in  their  assessment  quick  view> 

4.  10  Assessor  may  click-hold  the  assessment  plot  point  to  pop  up  a  scatter-plot  of 
the  assessed  indicators. 

5.  10  Assessor  may  scroll  through  the  indicator  list  if  it  is  longer  than  the  screen 
height  will  permit. 

Notes/Issues: 

•  None. 
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Use  Case:  Add  a  new  Assessment  to  an  Indicator 


Description:  The  10  Assessor  inputs  a  new  assessment  for  an  indicator. 

Pre-Conditions: 

•  The  10  Assessment  tool  must  be  loaded  with  plan  data. 

Post-Conditions: 

•  SUCCESS  -  New  Assessment  added.  Display  updated. 

•  FAILURE  -  Canceled  out  of  Assessment. 

Steps: 

1 .  10  Assessor  selects  a  Plan  element  from  the  Plan  Tree  View. 

<Plan  Element  is  shown  in  the  detailed  graph  and  indicator  list> 

2.  10  Assessor  double-clicks  an  indicator  in  the  indicator  list. 

<The  Indicator  Editor  Pops  up,  populated  with  the  current  assessment  data.  > 

3.  10  Assessor  edits  the  data  as  necessary. 

4.  A  justification  MUST  be  entered. 

5.  10  Assessor  clicks  the  “Commit  Changes”  button. 

<A  new  indicator  assessment  for  that  indicator  is  created  and  added  to  that 
indicators  history.  > 

<Assessment  rollups  that  are  fed  by  the  updated  indicator  are  recalculated.  > 
<The  display  is  updated,  where  necessary  to  reflect  the  new  Assessment  and 
Assessment  rollup.  > 

Notes/Issues: 

•  None. 
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Use  Case:  Adjust  Indicator  Weights 

Description:  The  10  Assessor  modifies  the  weights  for  the  set  of  indicators  associated  to 
a  plan  element. 

Pre-Conditions: 

•  The  10  Assessment  tool  must  be  loaded  with  plan  data. 

Post-Conditions: 

•  SUCCESS  -  Weights  adjusted.  Display  updated. 

•  FAILURE  -  Canceled  out  of  Weight  adjustment. 

Steps: 

1 .  10  Assessor  selects  a  Plan  element  from  the  Plan  Tree  View. 

<Plan  Element  is  shown  in  the  detailed  graph  and  indicator  list> 

2.  10  Assessor  clicks  the  ‘Edit  Weight  Set’  button  associated  with  the  group  of 
indicators  that  are  to  be  edited. 

<The  Weight  Set  Editor  Pops  up,  populated  with  a  list  of  the  Indicators  in  the  set  and 
their  current  weightings.  > 

3.  10  Assessor  edits  the  data  as  necessary. 

4.  A  justification  MUST  be  entered. 

5.  10  Assessor  clicks  the  “Commit  Changes”  button. 

<A  weight  for  each  indicator  is  created  and  added  to  the  plan  element  history.  > 
<Assessment  rollups  that  are  fed  by  the  updated  indicator  set  are  recalculated> 

<The  display  is  updated,  where  necessary  to  reflect  the  new  weights  and  Assessment 
rollup.  > 

Notes/Issues: 

•  None. 
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Use  Case:  Adjust  Plan  Element  Child  Element  Weights 

Description:  The  10  Assessor  modifies  the  weights  for  the  set  of  plan  elements  that  are 
the  children  of  a  plan  element. 

Pre-Conditions: 

•  The  10  Assessment  tool  must  be  loaded  with  plan  data. 

Post-Conditions: 

•  SUCCESS  -  Weights  adjusted.  Display  updated. 

•  FAILURE  -  Canceled  out  of  Weight  adjustment. 

Steps: 

1 .  10  Assessor  selects  a  Plan  element  from  the  Plan  Tree  View. 

<Plan  Element  is  shown  in  the  detailed  graph  and  indicator  list> 

2.  10  Assessor  clicks  the  ‘Edit  Weight  Set’  button  associated  with  list  of  child 
elements  of  that  plan  element. 

<The  Weight  Set  Editor  Pops  up,  populated  with  a  list  of  the  Indicators  in  the  set  and 
their  current  weightings.  There  is  also  an  item  that  represents  the  weight  to  portion 
to  the  plan  elements  Direct  Indicators.  > 

3.  10  Assessor  edits  the  data  as  necessary. 

4.  A  justification  MUST  be  entered. 

5.  10  Assessor  clicks  the  “Commit  Changes”  button. 

<A  weight  for  each  child  plan  element  is  created  and  added  to  the  plan  element 
history.  > 

<Assessment  rollups  that  are  fed  by  the  updated  plan  elements  are  recalculated.  > 
<The  display  is  updated,  where  necessary  to  reflect  the  new  weights  and  Assessment 
rollup.  > 

Notes/Issues: 

•  None. 
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4.0  10  Assessment  Prototype  Functional  Description 


The  original  concept  graphics  were  revised  based  on  internal  peer-review  and  10 
SME  review  to  depict  two  different  basic  assessment  displays:  one  for  IFO,  and  a 
second  for  "active"  10.  These  are  depicted  in  Figure  3  and  Figure  4  respectively.  The 
functional  capability  and  visual  specification  for  the  interface  is  described  in  greater 
detail  in  Section  8. 

Note  that  no  interface  is  provided  to  manipulate  the  10  plan:  this  is  created  outside 
this  tool  and  imported  for  display.  Controls  are  available  to  set: 

1)  Assessment  values  associated  with  IFO  direction 

2)  Assessment  values  associated  with  IFO  magnitude 

3)  Assessment  values  for  duration  for  both  desired  and  collateral  indicators 
for  active  10. 

4)  Assessment  values  for  percent  reduction  in  capability  for  both  desired 
and  collateral  indicators  for  active  10. 

5)  Confidence  for  all  indicators,  both  IFO  and  active  10. 

6)  Weights  for  all  indicators  and  subordinate  operations. 
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Figure  3:  Basic  IFO  assessment  display,  with  a  direction/magnitude  grid. 
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Figure  4:  Basic  Active  10  assessment  Display,  with  a  duration/degree  capacity 
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5.0  Identification  of  prototype  tool  shortcomings  and  areas  for  improvement 


The  prototype  assessment  tool  was  evaluated  internally  by  a  mix  of  human  factors 
engineers  and  by  10  SMEs  currently  supporting  the  JIOWC  and  familiar  with  the  10 
assessment  process.  Overall  findings  were  quite  positive,  with  several  general 
comments  on  good  features: 

1)  The  direction/magnitude  display  for  IFO  makes  sense  and  is  intuitive  to 
understand. 

2)  The  "active”  display  is  also  intuitive  to  understand  and  allows  rapid 
characterization  of  the  success  of  planned  operations. 

3)  Supporting  the  mix/match  of  indicators  and  subordinate  operations  is 
flexible  and  supports  real-world  needs. 

4)  Controls  and  displays  for  assessed  values,  confidence,  weights,  and  age  are 
clear  to  understand  and  easy  to  use. 

5)  After  an  initial  walkthrough,  experienced  10  assessors  found  the  overall  tool 
intuitive  to  use. 

The  evaluation  also  solicited  specific  weaknesses  in  the  tool.  To  support  the 
evaluation,  a  fictional  10  scenario  was  constructed,  "Operation  Healing  Voice,"  and 
an  XML  file  was  built  to  provide  an  assessment  snapshot  of  this  operation.  This 
allowed  SMEs  and  engineers  performing  the  evaluation  to  see  how  the  tool  worked 
in  context  with  an  operation.  The  scenario  used  for  evaluation  and  the  XML  file  used 
to  initialize  the  tool  can  be  found  in  Sections  9  and  10,  respectively.  Several  areas 
for  potential  future  improvement  were  identified  in  this  process,  and  are  discussed 
below: 

1.  Implement  a  capability  to  allow  assessment  of  performance/effort. 

2.  Provide  help  reference  to  10  TTPs. 

3.  Provide  mechanism  for  operator  to  define  the  indicator  sampling  technique. 

4.  Allow  for  review  of  justification  history. 

5.  Display  multiple  collateral  damage  effects  on  the  active  10  display. 

6.  Improve  the  Operator  Interface. 

7.  Alter  the  depiction  of  active  10  desired  or  collateral  effects  to  ovals. 

8.  Provide  a  detailed  "analyst’s  view"  toggle  for  the  active  10  display  to  include 
point  &  click  editing  of  effects  bounds. 

9.  Provide  a  stand-alone  capability,  including  local  Op / effect  input  screens  and 
database. 

10.  Allow  expected  magnitude  to  be  set  by  indicator,  rather  than  by  effect. 


Implement  a  capability  to  allow  assessment  of  performance /effort 

Current  EBO  doctrine  calls  for  establishing  both  Measures  of  Performance 
(MoPs),  and  Measures  of  Effectiveness  (MoEs).  The  prototype  tool  focuses 
exclusively  on  MoEs  and  their  indicators.  As  discussed  earlier,  this  design  decision 
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was  based  on  the  observation  that  performance  (i.e.,  effort),  especially  for  IFO,  is 
difficult  to  measure  in  a  uniform,  repeatable  fashion.  Displays  can  certainly  be 
added  to  evaluate  MoPs,  but  the  fundamental  issue  of  uniform  measurement  must 
be  addressed  at  the  level  of  10  Tactics,  Techniques  and  Procedures  (TTP),  in  order 
to  allow  a  meaningful  comparison  either  within  or  between  10  operations.  This  will 
require  significant  SME  input,  and  subsequent  acceptance  by  the  10  community. 

Provide  help  reference  to  10  TTPs 

Within  the  realm  of  effects,  the  criteria  for  evaluating  effects  based  on 
indicators  follows  TTPs  (business  process  rules),  that  range  from  global  to 
operation  specific.  Recognizing  that  assessors  will  vary  in  background  and  skill,  and 
that  the  assessment  of  IFO  in  particular  is  subjective,  help  screens  or  windows  that 
allow  the  operator  to  review  these  process  rules  in  context  to  setting  assessment 
values,  confidences,  and  weights  would  aid  in  maintaining  consistent  assessments. 

Provide  mechanism  for  operator  to  define  the  indicator  sampling  technique 

Equally  important  to  assessment  as  selecting  a  measureable  indicator  is 
specifying  the  sampling  method  to  be  used.  No  provision  currently  exists  for  in  COA 
Sketch  or  the  assessment  tool  prototype  to  specify  sampling  method  for  an 
indicator.  A  related  issue  is  the  generation  of  an  Assessment  Information  Request 
(AIR)  needed  to  task  collection  assets  under  the  tactical  control  of  other  commands 
to  generate  the  data  needed  to  satisfy  the  sampling  method. 

There  is  also  an  opportunity  to  apply  statistical  theory  as  a  quality  control  measure 
to  the  sampling  method.  By  describing  the  stochastic  nature  of  an  indicator  and  the 
sampling  method  and  frequency  applied,  it  is  possible  to  predict  the  confidence 
yielded  by  a  given  sampling  technique.  This  is  currently  a  standard  procedure  in 
opinion  polling,  but  is  not  routinely  applied  to  other  sample  gathering  techniques 
such  as  employing  ISRD  assets.  This  can  be  used  to  determine  if  a  given  indicator  is 
being  sufficiently  sampled,  and  just  as  usefully,  when  it  is  being  over-sampled  and 
squandering  a  scarce  collection  asset.  This  metric  does  not  address  whether  an 
indicator  is  appropriate  or  useful,  but  only  that  it  is  being  sufficiently  sampled  to 
reach  a  given  level  of  statistical  confidence. 

Allow  for  review  of  justification  history 

As  currently  implemented,  the  Assessment  Tool  requires  that  a  user  enter 
text  or  attach  documents  to  justify  each  change  in  assessment,  but  provides  no 
ability  to  review  past  justifications.  Such  review  is  essential  to  allow  an  analyst  to 
review  trend  data.  Suggested  functionality  includes: 

Scroll  backwards  in  time  through  assessment  justifications,  showing  each 
justification  or  attached  file  in  chronological  order. 

Provide  symbols  on  the  assessment  display  to  show  the  approximate 
position  of  the  displayed  justification  on  the  assessment  trend-line. 
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Display  the  actual  date  of  the  justification. 

Update  the  displayed  indicator  values  (weight,  assessed  value,  color) 
consistent  with  the  point  in  time,  and  provide  an  indication  of  which 
indicator’s  justification  is  being  displayed. 

A  concept  for  the  history  review  interface  is  shown  in  Figure  5.  Note  that  this 
should  be  a  modal  display:  The  user  may  review  the  history  of  indicator  changes, 
but  cannot  adjust  indicator  values  or  alter  roll-up  assessments  while  in  this  mode. 

Display  multiple  collateral  damage  effects  on  the  active  10  display 

Based  on  user  feedback,  multiple  collateral  effects  may  result  from  10  actions.  The 
most  significant  effects,  not  just  a  single  effect,  should  be  viewed  on  the  Active  10 
display.  To  avoid  rarely  used  complexity,  it  is  suggested  that  the  maximum  number 
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Justrfication/file  history  area.  As  you  go  "back  in  time"  the 
cursor  "Q"on  the  history  line  approximates  the  date,  and 
the  indicator  for  the  displayed  justification  is  highlighted. 


Justification  history  should  also  allow 
attached  files  used  for  justifications  to  be 
opened  in  another  window  for  review 


The  roll-up  assessment 
display  should  not  be 
affected  by  the  indicator 
history  (grayed  out).  It  needs 
to  be  clear  to  the  user  that 
this  is  a  review  of  indicator 
assessments. 

As  justifications  move 
backwards  in  time,  the 
indicator  being  displayed 
should  be  highlighted,  and  its 
data  reflect  the  changes. 
Scrolling  back  and  forth  in 
the  history  window  should 
allow  toggling  between  the 
older  and  newer  states/data. 

Subordinate  operation 
roll-ups  should  not  be 
affected  by  the  history 
scroll-back.  History 
reviews  only  indicator 
justifications  and  values. 

In  fact,  these  roll-ups 
should  be  grayed  out  to 
avoid  confusion. 


The  location  of  the  history  cursor  on  the  trendline 
should  vary  with  scroll  control  -  start  out  on  current, 
then  slide  back  to  show  the  approximate  point  on  the 
trendline  when  an  update  occurred. 


Figure  5:  Indicator  History  Concept 
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of  collateral  effects  displayed  for  a  single  10  task  be  three.  This  does  not  mean  that 
the  user  may  only  choose  three  collateral  effects.  Multiple  indicators  may  be 
assigned  and  weighted  to  allow  a  sum  of  minor  effects  be  displayed  as  a  single 
summary  effect.  In  fact,  with  the  display  limit  of  three,  a  useful  convention  may  be 
to  display  the  two  most  significant  collateral  effects,  and  a  summary  for  remaining 
minor  effects.  The  presence  of  multiple  effects  requires  that  a  weighting  scheme  be 
implemented  to  summarize  collateral  effects  for  the  purpose  of  roll-up. 

A  possible  method  of  display  for  multiple  collateral  indicators  is  depicted  in  Figure 
6.  In  the  concept  shown,  collateral  effect  bounds  and  assessed  points  are  shown  as 
transparent  over-lays,  with  the  degree  of  transparency  shown  by  the  order  in  the 
stack.  The  currently  selected  collateral  effect  area  is  displayed  as  a  solid  fill.  Non- 
selected  areas  are  displayed  as  partially  transparent  fills  behind  this  solid  layer. 
Non-selected  assessed  points  are  depicted  as  partially  transparent  foreground 
symbols. 

With  these  characteristics,  this  has  a  weakness  in  obscuring  a  smaller  "background” 
allowable  effect  area  under  the  foreground  area,  but  preserves  the  "background" 
assessment  "X"  to  indicate  the  presence  of  another  assessment  for  review. 


Improve  the  Operator  Interface: 

Several  minor  changes  to  the  user  interface  were  suggested  based  on  a  human 

engineering  review.  These  include: 

1)  It  is  not  obvious  that  the  indicator  bars  on  the  right  side  of  the  display  can  be 
double-clicked  to  adjust  an  indicator.  To  improve  their  affordance,  it  is 
recommended  to  make  them  single-click  to  open  and  give  them  some  mild 
hover  effect  when  moused-over,  possibly  a  background  color  change. 
Incorporating  this  difference  will  also  let  the  user  know  when  it  can  be 
clicked  on  or  not  since  it  is  not  always  interact-able,  e.g.,  in  the  edit  weight  set 
window. 

2)  Subordinate  operation  bars  on  the  right  side  of  this  display  necessarily 
behave  differently  than  the  indicator  bars.  It  is  recommended  that 
subordinate  operation  bars  should  be  represented  somewhat  differently  to 
avoid  confusion  by  the  operator.  A  separate  control  could  be  provided; 
however,  the  tradeoff  between  adding  an  additional  control  versus 
increasing  display  clutter  would  need  evaluated.  Additional  feedback  from 
actual  operators  can  refine  this. 

3)  It  has  been  recommended  that  the  operation  level  displayed  in  the  center 
graphic,  whether  IFO  or  active  10,  should  be  highlighted  in  the  Assessment 
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Figure  6:  Multiple  Collateral  Effects  Concept  for  Active  10 
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Explorer.  Currently,  the  prototype  initializes  by  showing  the  summary 
operation  level,  "Operation  Healing  Voice,"  but  this  is  not  highlighted  in 
Assessment  Explorer. 

4)  It  is  recommended  to  remove  the  “X"  for  closing  the  window  from  the  "Edit 
Weight  Set"  window  to  prevent  the  operator  from  clicking  the  X  rather  than 
using  the  Commit  Changes  button  and  thinking  they  actually  made  changes. 

5)  When  there  is  only  one  indicator,  the  edit  weight  selection  is  irrelevant;  thus, 
it  is  recommended  to  disable  the  edit  weight  selection  button  under  this 
circumstance,  to  avoid  confusion  and  frustration  on  the  part  of  an  operator 
who  may  not  understand  why  the  button  exists  but  does  not  work. 


Alter  the  depiction  of  active  IQ  desired  or  collateral  effects  to  ovals. 

(SME  input  required)  Currently,  rectangular  regions  are  used  to  display 
desired  and  collateral  effects  bounds  in  terms  of  duration  and  degree  of  effect.  It  is 
likely  that  this  may  overstate  the  limits  of  these  bounds  near  the  corners  of  the 
rectangle  when  both  factors  are  approaching  their  limits.  An  alternate  to  this 
display  is  an  oval  region  defined  at  a  minimum  by  semi-major/minor  bounds  that 
correspond  to  duration/degree  of  effect.  However,  as  effects  bounds  are  not 
necessarily  symmetrical,  the  mathematically  attractive  solution  of  displaying  a 
simple  ellipse  is  insufficient.  This  is  an  area  for  mathematical  exploration  before 
committing  to  graphics  prototypes,  as  a  rigorous  solution  that  lends  itself  to  roll-up 
calculations  may  prove  quite  complex.  The  class  of  shapes  known  as  Cassini  ellipses 
and  also  Super  ellipses  may  be  useful,  though  the  rigorous  solution  probably  falls 
into  the  complex  area  of  general  elliptical  curves. 

Provide  a  detailed  “analyst's  view"  toggle  for  the  active  IQ  display  to  include  point  & 
click  editing  of  effects  bounds. 

The  current  active  10  display  uses  multiple  x-axis  time  scales  on  a  single 
display  to  provide  at-a-glance  comparison  of  the  rough  durations  of  effects  between 
10  tasks.  However,  this  same  display  poorly  supports  the  precise  interpretation  of 
durations  by  an  analyst  -  at  the  right  side  of  the  display,  the  difference  of  a  few 
pixels  is  a  large  change  in  duration. 

This  display  should  be  able  to  be  toggled  to  a  single,  uniform  scale,  selected  by  the 
user.  If  the  collateral  area  on  the  scale  selected  extends  beyond  the  display  limits, 
either  a  pan  control  to  move  the  windowed  area  of  the  display  on  the  scale  or  a  scale 
change  should  be  implemented.  Implementing  this  "analysts’  view"  would 
potentially  allow  a  click-and-drag  interface  for  setting  or  modifying  effect 
boundaries. 
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Provide  a  stand-alone  capability,  including  local  Op /effect  input  screens  and 
database. 


As  alluded  to  in  the  paragraph  above,  a  stand-alone  capability  to  enter  at 
least  a  rudimentary  10  plan,  designating  effects  and  indicators,  is  desired  to  support 
smaller  operations,  locally  controlled  10  operations,  and  compartmented  activities. 
Ideally,  this  interface  should  be  simple,  with  immediate  feedback  of  the  result.  One 
suggested  interface  is  to  start  with  a  blank  tree  view,  that  contains  a  single,  blank 
"Operation."  Right-clicking  on  this  blank  operation  would  allow  a  user  to  enter: 
Descriptive  information  for  the  selected  element. 

Creation  of  a  new  operational  effect  subordinate  to  the  selected  level 
(tactical  objective,  IFO  or  10  tactical  task,  etc.). 

Creation  of  a  new  indicator  subordinate  to  the  selected  level. 

In  this  manner,  a  user  familiar  with  the  conventions  of  the  display  could  rapidly 
construct  a  small  plan  from  a  blank  tree,  populating  it  with  related  indicators  and 
subordinate  tasks,  by  building  and  describing  effects  and  indicators  subordinate  to  a 
selected  level. 

Paired  with  this  capability  would  be  a  locally  resident  database  capable  of  storing 
both  the  plan  and  its  history  data. 

Allow  expected  magnitude  to  be  set  by  indicator,  rather  than  by  effect. 

In  the  Despotistan  scenario,  a  desired  IFO  effect  was  to  influence  the  government  to 
allow  NGO  workers  supported  by  foreign  military  to  enter  the  country  unmolested 
by  either  national  troops  or  local  militias.  Since  the  desired  effect  impacted  the 
entire  country,  the  magnitude  assigned  was  equal  to  the  population  (24,000,000). 
However,  the  magnitude  indicators  used  to  determine  the  effect  are  numerically 
much  smaller:  detection  of  messages  urging  cooperation  on  official  Despotistan 
broadcast  channels  (say  five  channels  possible),  and  observation  of  the  withdraw  of 
heavy  brigades  from  the  border  (say  twelve  brigades). 

In  this  case,  the  expected  magnitude  for  each  indicator  differs  from  the  expected 
magnitude  of  the  effect:  it  can  be  argued  that  this  is  not  an  exceptional  instance,  but 
a  normal  occurrence  in  IFO  assessment.  It  would  be  simpler  for  the  assessor  if 
indicator-specific  expected  magnitudes  could  be  assigned  and  displayed  for  each 
indicator,  so  that  the  assessor  is  entering  real-word  numbers  for  the  indicator 
rather  than  scaling  the  value  in  their  head:  the  software  can  scale  and  weight  the 
indicators  for  display  in  the  overall  effect  summary. 

Essentially,  IFO  assessment  can  be  characterized  as  describing  a  population  through 
a  sort  of  clustered  sampling  method,  using  one  or  more  sample  frames  and  sampling 
weights.  Thus  in  the  example  above,  we  are  attempting  to  describe  the  receptivity 
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of  the  population  of  Despotistan  to  foreign  intervention  by  using  two  different 
sampling  frames:  1)  the  content  of  government-controlled  broadcasts,  and  2)  the 
behavior  of  forward  based  troops.  Within  these  frames,  the  assessor  will  need  to 
articulate  a  sampling  strategy  (e.g.,  When  do  I  listen?  How  often  do  I  look?).  The 
recommended  change  recognizes  that  these  two  frames,  while  assumed  to  have  a 
correlation  to  the  affected  population,  in  reality  have  their  own  individual 
magnitude.  With  this  approach,  if  the  assessor  can  fully  characterize  the  size  and 
distribution  of  the  sample  frame,  it  is  possible  to  evaluate  his  selected  sample 
strategy  and  assign  a  confidence  limit, 
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6.0  Assessment  concept  slides 

The  following  10  assessment  concepts  slides  were  presented  December  19,  2007 
elicitation  of  10  planners  at  the  Joint  Information  Operations  Warfare  Center 
(JIOWC). 
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Effect  Assessment  Concept 


*  Based  off  media  analysis 
concept,  with  two 
components: 

—  Direction:  Perceived 
positive  or  negative 
effect 

—  Magnitude:  Portion  of 
target  population 
influenced 
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Multiple  PEL  Summary 


Basic  Features 


Semi-log  Region 

-  allows  for 
magnitude 


Linear  Region 

-  Magnitude  ^ 

-  Direction 
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0 

Direction 


Color  banding  provides 

at-a-glance 

interpretation 

‘  Magnitude  scale 
based  on  expected 
magnitude  for  a  given 
target. 
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Drill-down  to  single  PEL 
provides: 

—  Confidence  bound  for 
most  recent  data 

—  Trend  over  time 

•  User  selected 
period 

•  Symbols  denote 
approximate  data 
age 


PEL  #3:  Last  90  Days 
+  =  Current 
O  =  0  to  30  days 
□  =  31  to  60  days 
A  =  61  to  90  days 


msL 


V 

Confidence  Presentation 

n 
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Value  Model  for  Effect  Computation 


x'-  Indicator  ^  1  :onfidence 


Scoring 

s — * 

Confidence 

Scoring 

s — 1 

Confidence 

— x  W1 


For  a  given  PEL: 

-  Analyst  collects  raw  indicators 

-  Analyst  assigns  normalized  score  in  direction  or  magnitude 

-  Analyst  assigns  weight  for  computed  roll-up  to  summary  level 

-  Analyst  assigns  confidence  in  individual  assessment  for  bounds 


SMC 
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Indicator  Considerations 


*  Cultural  understanding  is  critical  to  accurate  assessment 

—  A  very  positive  message  to  one  community  may  be  neutral  or 
negative  to  another. 

*  e.g.,  U.S.  border  security  and  immigration  laws 

♦  Indicators  for  an  effort  are  not  limited  to  media  sources 

—  Internal  reports  regarding  behavioral  changes  in  populations, 
e.g.  rally  turn  out. 

—  Campaign  donations/trends 

—  Voter  registrations 

—  Poll  results/trends 

•  Non  media  indicators  may  contribute  to  either  magnitude  or 
direction,  as  the  analyst  determines 

SA  Ef~ 

_ .v-;;— 

fix**  Senna  ta  Soi&onr* 
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7.0  Trip  Report  for  December  19,  2007  Elicitation  at  the  TIOWC 

The  following  trip  report  applies  to  the  elicitations  of  10  planners  conducted 
regarding  10  assessment,  December  19,  2007  at  the  Joint  Information  Operations 
Warfare  Center. 
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Dec.  19,2007. 


JIOWC  leadership  opened  with  an  overview  of  the  GEM-S,  and  described  VisIOn  as  a 
marriage  of  JIAPSE  and  IOPC-J /X.  The  two  take-away  messages  from  the  current 
horse-blanket  is  a  lack  of  synchronization  and  a  lack  of  activity.  Goal  for  January  is 
some  stand-alone  capability  to  mechanize  the  horse-blanket.  A  parallel  activity  is  to 
obtain  data  for  entry  into  the  tool.  From  January  to  June,  try  to  connect  the  tool  to 
other  COCOMs,  others. 

The  elicitation  was  conducted  at  the  unclassified  level. 

Participant  background: 

1.  Career  Army  Intel,  planning  Intel  OPS.  Last  7  years  in  I/O.  Currently  working 
Joint  OPS  and  Plans.  Mix  of  Intel  and  I/O  operations.  Characterized  I/O  in  the 
following  manner: 

EW  alone  is  not  I/O 
CNO  alone  is  not  I/O 
PSYOPS  alone  is  not  I/O 

I/O  is  a  combination  of  techniques  to  achieve  an  effect.  Also  characterized  the  bulk 
of  the  horse  blanket  activities  as  Influence  OPS,  and  in  large  part,  not  a  DoD  mission. 
DoD  controlled  activities  are  very  minor.  Others  lead  the  influence  area,  in 
particular  DoS.  Was  very  clear  that  in  order  to  make  GEM-S  "work",  it  needed 
direction  from  the  NCA  level  for  multiple  departments  and  agencies  to  play  together. 
Build  it  and  they  will  come  -  perhaps  not.  "Hope  is  not  a  strategy". 

Read  between  the  lines  (but  not  by  much):  Regards  the  author  of  the  horse  blanket, 
as  a  smart  guy  who  sees  the  "big  picture",  but  is  reaching  beyond  his  ability  in 
attempting  to  bring  the  horse  blanket  as  an  integrated,  active,  multi-agency  effort  to 
fruition.  Thinks  it  will  die  on  the  vine  -  which  he  states  is  not  our  problem. 

2.  Ten  years  in  USAF  Intel,  including  past  assignment  to  NSA.  First  tour  in  I/O. 

Focus  is  on  assessing  current  I/O  Ops.  Current  activity  is  on  Operation  Assured 
Voice,  out  of  EUCOM,  focused  on  Africa.  Current  state  of  I/O  assessment  is 
haphazard  and  ad  hoc.  Have  started  developing  their  own  assessment  tools  (JEMA, 
Joint  Effects  Modeling  and  Assessment)  -  see  separate  hard  copy.  They  are  reach 
back  for  EUCOM. 

Use  EBO  methodology,  with  assessment  tied  to  MoEs  and  indicators.  Things  they 
are  running  into: 

-  Lots  of  dependency  on  OSINT:  commercial  polls,  websites,  and  foreign 
media  analysis. 

-  Traditional  Intel  reports  and  collections  don’t  meet  needs.  Example:  an 
indicator  may  be  the  portion  of  inter-sect  marriages.  Intel  shop  shrugs  and  asks, 
How  do  we  collect  against  that?  May  rely  on  NGO  sources. 

-  Blue  Force  OSINT  -  walking  around  observsations. 

-  Many  stove  pipes  for  collected  data,  obstacles  to  sharing 
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-  Difficulty  in  correlating  the  data  (data  volume  issue),  and  how  to  weight  the 
data  -  what  is  the  importance  of  any  individual  item? 

Commissioning  commercial  polls:  See  below,  from  an  email  with  unclassified  end- 
state  and  indicators  examples: 

"Here's  the  document  I  would  like  you  to  pass  to  Tom.  Treat  the  blue  as"end 
state",  the  red  as  PELs  and  the  black  as  MOE  and  indicators  (we've  collapsed  them 
here  and  taken  them  out  of  their  MOE  and  indicator  categories  for  sanitization 
purposes).  It's  rudimentary  b/c  I  had  to  eliminate  a  lot  of  detail  but  gives  you  the 
idea  of  how  the  process  trickles  down.  If  you  provide  me  a  SIPR  email  I  can  send 
down  the  actually  PELs  and  provide  more  detail. 

Intent:  Minimize  violent  extremist  ideology  in  the  region  of  interest 

Goal:  Influential  host  nation  "moderates”  speak  out  against  extremism 
(Influential  host  nation  population  actively  opposes  extremism  in  their 
country;  they  speak  out  again  extremist  ideology.  Potential  communicators 
can  be  religious  and  political  leaders,  media  personalities  and  outlets, 
business  leaders  and  celebrities) 

Potential  Measurements: 

-  Increase/Decrease  (I/D)  of  instances  of  moderate  statements  in  the  host  nation 
media 

-  Increase/Decrease  (I/D)  Size  of  moderate  media  audience 

-  Increase/Decrease  (I/D)  in  population’s  belief  that  extremism  is  damaging  to  their 
country  or  a  threat  to  their  culture 

-  Increase/Decrease  (I/D)  leadership  effort  to  police  extremist  organizations 

-  Increase/Decrease  (I/D)  civic  /  non-profit  organizations  that  promote  moderate 
ideology  (or  oppose  radical  /  extremist  ideology) 

-  Increase/Decrease  (I/D)  population  "turn  in"  or  "reporting”  of  radicals  or 
extremist  activity  (assists  security  services) 

-  Increase/Decrease  (I/D)  in  successful  anti-extremist  operations  by  local  forces 
(arrests,  breaking  up  cells,  foiling  plots  etc.) 

Goal:  Extremist  /  radical  organizations  and/or  their  leaders  are  discredited 
(Extremist  organizations  or  their  leaders  are  no  longer  seen  as  effective  or 
reputable;  they  are  no  respected  by  their  followers,  the  host  nation  population 
or  other  extremist  organizations) 

Potential  Measurements 

-  Increase/Decrease  (I/D)  Instances  of  "desertion"  or  "reform"  of  operatives  from 
extremist  organizations 
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-  Increase/Decrease  (I/D)  internal  conflicts  within  extremist  organizations,  such  as 
splinter  groups  forming  or  power  struggles  between  factions  or  rival  leaders  vying 
for  group  /  population  loyalty 

-  Increase/Decrease  (I/D)  in  negative  mass  media  coverage  of  violent  extremist 
organizations 

-  Increase/Decrease  (I/D)  in  name  recognition  of  extremist  leadership 

-  Increase/Decrease  (I/D)  in  passive  support  within  population  for  extremist 
organizations 

-  Increase/Decrease  (I/D)  Instances  of  monetary  /  in  kind  donations  to  extremist 
groups 

-  Increase/Decrease  (I/D)  population  "turn  in"  or  "reporting”  of  radicals  or 
extremist  activity  (assists  security  services) 

-  Increase/Decrease  (I/D)  in  successful  anti-extremist  operations  by  local  forces 
(arrests,  breaking  up  cells,  foiling  plots  etc.) 

Goal:  Host  nation  governments  collaborate  with  external  partners  on  counter¬ 
extremist  initiatives 

(Host  nation  governments  collaborate  with  external  /  regional  partners; 
cooperative  efforts  with  regard  to  illegal  trafficking  and  other  criminal 
activity) 

Potential  Measurements: 

-  Host  nation  participates  in  regional  security  related  information  sharing  or 
security  agreements 

-  Host  nation  participates  in  international  agreements  and  treaties  on  anti-terrorist 
issues  (i.e.  extraditions,  assistance,  border  security  cooperation,  exercises  etc.) 

Goal:  Host  nation  population  adopts  an  anti-extremist,  anti-radical  ideology 
(Population  actively  opposes  extremism  in  their  country;  they  speak  out  again 
extremist  ideology) 

Potential  Measurements: 

-  Increase/Decrease  (I/D)  of  instances  of  moderate  statements  in  the  host  nation 
media,  to  include  anti-extremist  editorials 

-  Increase/Decrease  (I/D)  Size  of  moderate  media  audience 

-  Increase/Decrease  (I/D)  of  Instances  of  moderate  communication  forums,  ie.  Web 
sites,  blogs,  clubs 

-  Increase/Decrease  (I/D)  Instances  of  moderate  messages  in  civic/public  forums,  to 
include  demonstrations,  civic  action  groups 

-  Increase/Decrease  (I/D)  in  moderate  /  anti-extremist  positions  in  educational 
institutions/curriculums 

-  Increase/Decrease  (I/D)  in  Evidence  of  moderate  message  in  religious  discourse, 
schools,  or  places  of  worship 

-  Increase/Decrease  (I/D)  in  Instances  of  the  "normalization"  of  extremist  /  radical 
viewpoints  through  incorporation  into  mainstream  political  organizations  /  parties, 
vice  terrorist  platforms 
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-  Increase/Decrease  (I/D)  in  youth  or  college  student  opposition  to  extremist 
ideology 

-  Increase/Decrease  (I/D)  in  population’s  belief  that  extremism  is  damaging  to  their 
country  or  a  threat  to  their  culture 

-  Increase/Decrease  (I/D)  in  Evidence  that  host  nation  leaders  make  effort  to  police 
extremist  organizations 

-  Increase/Decrease  (I/D)  in  Evidence  of  civic  /  non-profit  organizations  that 
promote  moderate  ideology  (or  oppose  radical  /  extremist  ideology) 

-  Increase/Decrease  (I/D)  in  Evidence  that  host  nation  population  is  inclined  to 
"turn  in"  or  "report”  radicals  or  extremists  (assists  security  services) 

-  Increase/Decrease  (I/D)  in  Evidence  that  host  nation  is  successful  in  anti¬ 
extremist  operations  (arrests,  breaking  up  cells,  foiling  plots  etc.) 

-  Increase/Decrease  (I/D)  in  religious  tolerance 

-  Increase/Decrease  (I/D)  in  Instances  of  sectarian  violence 

-  Increase/Decrease  (I/D)  in  inter-sect,  inter-faith  or  inter-ethnic  marriage 

-  Increase/Decrease  (I/D)  in  religiously  /  ethnically  mixed  neighborhoods,  schools 

Goal:  Extremist  organizations'  cyber  presence  is  diminished 
(Extremist  groups  cyber  activity  is  non-productive,  presence  on  the  web  is 
reduced;  creation  of  training  resources  is  minimized) 

Potential  Measurements: 

-  Evidence  of  extremist  presence  on  the  web 

-  Instances  of  extremist  ideology  in  moderate,  mainstream  web  sites 
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Constructing  Operation  Assured  Voice  (OAV): 

Used  SIAM  (http://www.inet.saic.com/inet-public/),  to  construct  a  nodal 
analysis,  create  effects,  MoEs,  and  indicators.  SIAM  generates  the  PEL.  (Note  that 
SIAM  is  now  an  SAIC  company,  and  this  is  Java-based  software  -  need  to  see  if  we 
can  get  documentation/API). 

Big  problem  comes  in  attempting  to  link  information  to  indicators. 
Information  that  comes  in  is  rated  on: 

-  a  scale  of  1:10  for  applicability. 

-  Good/Bad/Neutral 

-  L/M/H  confidence 

All  of  these  ratings  are  "judgment  calls". 

One  critical  aspect  of  evaluating  an  operation  is  obtaining  a  baseline  of  the 
indicators  prior  to  the  start  of  the  operation,  as  a  point  of  comparison:  are  you 
making  things  better,  worse? 

May  be  100  web  sites  influencing  an  area,  be  we  are  monitoring  perhaps  2. 
Everything  we  are  dealing  with  is  a  soft  target.  You  are  rarely  sure  of  the  effect. 

Doing  assessment  right  is  more  expensive  in  resources  and  manpower  than 
conducting  the  I/O  operation. 

When  coordinating  with  kinetic  folks,  need  to  warp  the  EBO  constructs  used  in  Intel 
to  the  strat-to-task  constructs  still  being  used  by  others. 

The  desired  end-state  should  be  driving  both  the  OP  and  assessment.  The  end-state 
consists  of  3-4  sentences. 

Outside  of  a  major  DoD  operation  (OEF,  OIF,  etc.),  then  influence  OPS  and  I/O  in 
general  is  worked  through  the  embassy,  thus  DoS  and  other  agency  coordination 
come  into  play.  No  evidence  of  EBO  planning,  or  anything  the  DoD  recognizes  as 
formal  planning  on  the  DoS  side.  Notes  that  the  NIP  was  done  at  the  NCA  level  -  and 
that  to  achieve  the  vision  of  GEM-S,  that  direction  will  have  to  come  from  that  level 
as  well.  For  GEM-S  to  achieve  even  DoD  acceptance,  it  must  have  clear  utility  for  a 
commander.  COCOMs  work  tactical  I/O  in  their  theatres  -  not  necessarily 
coordinated  with  JIOWC.  (From  the  Army  1st  I/O,  notes  that  they  have  developed 
I/O  specific  icons,  a  la  MIL-STD-2525,  for  internal  use). 

Clear  that  both  officers  are  attempting  to  interpret  and  correlate  the 
information  contained  in  separate  panes  of  the  PowerPoint,  and  are  getting 
confused  in  chart  inconsistencies.  This  is  not  intuitive  (four  panel  chart).  Confusion 
on  the  3D  icons  presented  as  well  -  what  did  it  mean?  Need  to  walk  through  a 
consistent  use-case  and  build  that  case  from  slide-to-slide. 
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--  Concurrence  on  assessment  concept.  Checking  for  alternate  terms  for 
"direction"  and  "magnitude”  --  nothing  is  standardized  here,  so  lets  adopt  whatever 
is  closest  to  current  terminology. 

-  no  heartburn  with  fixed  gradient.  It  made  sense  to  them 

-  concurrence  on  widening  the  confidence  "bubble"  for  center-scale 
assessments.  Confirmed  that  analyst  often  place  things  they  are  uncertain  about 
center-scale. 

-  Need  to  have  a  user-defined  time  period  for  the  trend  display.  Binning  of 
periods  and  mapping  to  a  sparse  set  of  symbols  seems  OK. 

-  Need  to  separately  display  the  "baseline"  point  of  an  assessment. 

-  Magnitude  as  a  relative  measure:  Objective  may  be  a  single  leader.  May  be 
an  entire  population.  No  heartburn  with  the  semi-log  "viral"  area. 

On  observing  the  value-model  slide,  looked  at  it  for  a  few  moments,  and  then 
correctly  indicated  what  it  meant  (before  I  briefed  it),  saying  yep,  that  makes  sense. 
Also  concurred  on  the  continuation  of  the  roll-up. 

Overall  -  assessment  concept  seems  to  be  pretty  much  on.  Need  to  check 
terminology,  and  need  to  add  a  baseline  symbol. 

Also,  need  to  see  if  we  can  directly  import  assessment  info  from  JEMA  -  Seems  silly 
to  develop  yet  another  assessment  interface  if  one  exists  already. 
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8.0  Visual  and  Functional  Specification  of  the  10  Assessment  Prototype 

The  following  details  the  visual  and  functional  specification  of  the  10  Assessment  prototype. 


©  2008,  Science  Applications  International  Corporation 
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Clicking  on  a  element  will  bring  up  it’s  detailed  assessment  graph, 
indicator  list,  and  Sub  Op  Rollup  list  if  it  has  subordinate  tasks. 
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The  plan  tree  nodes  can  be  expanded  or  closed  using  the  triangles. 
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Element  Name 

Navigate  to  Parent 

Rollup  Info  for  this  element  (see 

Element 

Indicator  Summary  for  details) 

Detailed  Assessment  Graph 
(10  Assessment) 
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Direction  Indicators  ov<  ) 


Shows  plotted  assessment. 


Plot  based  on  rollup  of  this 
elements  Indicators. 


If  the  Plan  Element  has 
subordinate  tasks,  these  are  also 
rolled  up  into  the  assessment 


Confidence  is  rolled  up. 


Age  of  assessment  is  based  on 
the  last  Indicator  assessment, 
which  triggered  the  most  recent 
rollup. 
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Here's  the  indicator  lists  and  sub  rollup  list  of 
this  “blown  up"  plan  element  assessment 


Detailed  Assessment  Graph 

(10  Assessment)  -  Subcomponent  Scatter  Plot  Details 


A  scatter  plot  of  all  the  plan  element 
components  that  make  the  rollup  is 
brought  up  when  the  user  clicks  and 
holds  down  the  left  mouse  button. 


Two  axis  lines  are  drawn  as  a  reminder  of  where 
the  "blown  up'  plan  element  rollup  is  located,  giving 
a  reference  point  for  the  component  plots. 
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30 

Magnitude  Indicator  Assessments  are  drawn  as  tic 
marks  along  the  Magnitude  Axis  at  their  individual 
assessed  values..  Their  length  reflects  their  weight. 
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Launches  Weight 


Scroll  Bar  will  activate  if 
indicator  list  exceed 
window  size. 


a 
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Indicator  Summary 


Hovering  over  the  different  components  brings  up  a 
tooltip  that  gives  the  exact  numerical  value  of  the  specific 
information. 

Hovering  over  the  Name  will  give  the  numerical  rollup 
values  for  that  indicator 
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10  Assessment  Gradient 
3D  Deconstruction 
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9.0  Fictional  Scenario  for  Prototype  Assessment  Tool  Evaluation 

The  following  details  the  fictional  scenario  for  the  prototype  assessment  tool 
evaluation. 
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Operation  Healing  Voice  --  Fictional  Scenario 


Background: 

The  country  of  Despotistan  has  been  a  closed  society  since  the  overthrow  of  the 
monarchy  by  a  military  junta  some  forty  years  ago.  Since  that  time,  the  junta  has 
controlled  all  media  within  the  country,  and  has  efficiently  jammed  foreign 
broadcasts.  For  their  own  part,  they  have  offered  a  national  message  of  total 
independence  and  self-reliance,  in  keeping  with  the  principles  animalistic  state 
religion.  The  message  also  portrays  all  foreigners  as  enemies  and  usurpers,  to 
be  turned  back  at  every  sighting. 

This  has  not  prevented  the  junta  from  benefiting  from  the  global  economy.  While 
most  of  the  country  is  agrarian,  they  have  trained  in  the  three  major  urban  areas, 
a  core  labor  force  in  both  electronic  assembly  and  small-scale  pharmaceutical 
production  (mostly  counterfeit  versions  of  drugs  still  under  patent),  and  offer  low 
cost  outsourcing  to  foreign  manufacturers  in  Europe  and  Asia  -  with  all  contacts, 
and  profits,  strictly  controlled  by  the  ruling  junta. 

To  aid  in  educating  and  maintaining  this  workforce,  the  junta  has  allowed  the 
introduction  of  computer  technology,  including  limited  Internet  access,  to  the 
civilian  population.  While  private  ownership  is  officially  banned,  Internet  kiosks 
are  common  in  the  urban  areas,  and  are  spreading  into  the  rural  area.  Intranet 
communication  within  the  country  is  monitored,  but  otherwise  unencumbered. 

The  external  Internet  and  telecommunications  circuits  are  effectively  firewalled 
and  monitored  by  the  junta  to  prevent  external  contacts.  Official  government 
communications  within  the  country  are  routinely  and  effectively  encrypted.  Only 
radio  and  television  broadcasts  targeting  the  local  population  are  made  in  the 
clear. 

There  is  limited  trade  of  goods  and  exchange  of  information  across  the  guarded, 
but  porous  mountainous  border  with  neighboring  Agraria,  which  while  tolerant  of 
the  Despotistan  government,  maintains  good  ties  with  the  West. 

Despotistan  lacks  an  effective  airforce,  having  a  roughly  20  EMB-314  Super 
Tucano  propeller  attack  aircraft  and  another  20  MI-17  transport  helicopters,  some 
of  which  are  believed  to  be  operated  as  light  gunships. 

Air  defense  capability  consists  of  Chinese  manufactured  AAA  and  QW-4 
MANPAD  missiles  deployed  with  ground  units. 

Despotistant  ground  forces  are  formidable  for  the  region,  centered  on  a  force  of 
100  Chinese  Type  88B  main  battle  tanks,  and  an  additional  150  infantry  fighting 
vehicles:  30  ZSD89  tracked  APCs,  and  90  wheeled  ZSU-92s  IFVs,  and  30, 
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ZFB05  lightly  armored  4x4s.  Heavy  units  are  tightly  controlled  by  the  central 
government,  with  ZSU  and  ZFB  equipment  found  in  local  garrisons. 


Crisis  timeline: 

Rumors  of  a  plague  in  Despotistan  have  been  communicated  by  border  traders 
and  smugglers  in  the  neighboring  country  of  Agraria.  Twenty  six  days  ago,  a 
series  of  unsecured  communications  were  intercepted  from  the  Despotistan  town 
of  Varicelle,  concerning  an  outbreak  of  disease  among  workers  living  near  a 
pharmaceutical  factory.  Subsequently  encrypted  government  communications 
within  Despotistan  increased  dramatically,  and  satellite  imagery  shows  that 
troops  have  deployed  towards  the  border  region.  Despotistan  public  broadcast 
channels  called  for  a  nationwide  travel  ban  enforced  by  the  military  for  “reasons 
of  national  sovereignty  and  security”,  but  offered  little  additional  insight. 

Twenty  days  ago,  a  contact  was  lost  with  a  small  mountain  border  village  in 
Agraria.  Agraria  government  workers  investigating  the  village  confirmed  that  all 
of  the  villagers  were  dead,  with  symptoms  of  an  hemorrhagic  illness  combined 
with  blackened  skin  on  the  face  and  extremities  and  in  the  more  recent  dead,  red 
eyes.  NGO  medical  personnel  recognized  the  symptoms  as  classic  hemorrhagic 
smallpox,  and  used  vaccinated  workers  to  quarantine  the  government  workers 
and  obtain  samples  that  were  sent  to  the  Centers  for  Disease  Control.  Six  days 
ago  the  CDC  confirmed  that  the  samples  were  a  partial  match  to  the  Rahima 
strain  of  smallpox  -  a  strain  found  in  the  WHO  repositories.  Four  days  ago,  the 
government  workers  died,  and  the  vaccinated  NGO  medical  personnel  caring  for 
them  developed  first-stage  symptoms  of  hemorrhagic  small  pox.  Two  days  ago, 
the  CDC  informed  the  NCA  that  the  smallpox  was  a  genetically  modified, 
weaponized  version  of  the  Rahima  strain  (GMPOX),  that  included  a  human 
interleukin  4  (IL-4)  gene,  rendering  conventional  vaccination  therapy  ineffective 
for  containment.  An  experimental  former-Soviet  vaccine  from  the  Biopreparat 
program  is  known  to  have  greater  efficacy  against  this  modified  virus. 
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Intel  summary: 


1 )  High  confidence:  With  or  without  the  knowledge  of  the  Despotistan 
government,  a  pharmaceutical  plant  in  the  town  of  Varicelle  was  producing 
IL-4  modified  smallpox  as  a  biological  weapon.  The  disease  escaped 
containment  and  began  uncontrolled  spread  in  the  local  population. 

2)  Fact:  IL-4  modified  smallpox  is  highly  contagious,  with  an  incubation 
period  of  twelve  days  from  contact  to  first  symptoms  (headache  and 
fever).  Death  typically  occurs  within  seven  days  of  the  onset  of 
symptoms,  with  modern  supportive  therapy.  The  dried  scabs  of  a  victim 
are  infectious  for  weeks  to  potentially  years  after  death,  depending  on 
environmental  conditions.  The  morbidity  and  mortality  rate  of  the  disease 
varies  with  the  vaccination  status  of  the  victim  as  shown  below: 

a.  Unvaccinated:  100%  mortality  within  21  days  of  contact 

b.  Conventional  vaccination 

i.  >  90  days  after  vaccination:  95%  morbidity,  80%  mortality 

ii.  At  least  14  days  prior  to  exposure,  but  within  90  days  of 
vaccination  :  80%  morbidity,  50%  mortality 

c.  Biopreparat  vaccine  at  Ieast14  days  prior  to  exposure  :  25% 
morbidity,  10%  mortality 

3)  High  confidence:  Despotistan  does  not  have  the  medical  means  to 
contain  the  disease,  and  are  relying  on  physical  quarantine  to  let  the  virus 
“burn  itself  out”  in  infected  cities.  Satellite  imagery  finds  military 
roadblocks  ringing  the  Varicelle  area,  with  evidence  of  a  shoot-on- 
approach  policy.  Border  checkpoints  and  military  hard  points  are 
configured  against  an  outward  threat. 

4)  Moderate  confidence:  IMINT  evidence  of  roadblocks  and  civil  disruption 
near  the  central  hospital  in  the  capital  city  of  Despotistan  indicate  that  the 
contagion  may  have  spread  there,  in  spite  of  the  roadblocks. 

5)  Moderate  confidence:  Limitation  of  the  availability  of  the  Biopreparat- 
Moscow  vaccine  precludes  preventative  vaccination  of  the  general 
population  of  the  West.  A  crisis  effort  is  underway,  but  suitable  stocks  for 
mass-vaccination  in  the  West  are  estimated  to  be  18  to  24  months  away. 

6)  High  Confidence:  Suitable  stocks  are  available  to  attempt  ring-vaccination 
containment  methods  at  the  Despotistan  border  and  urban  areas,  and 
have  been  offered  by  former  Soviet  governments. 

7)  Estimated  death  toll  if  the  virus  is  not  contained  to  Despotistan  ranges 
from  40  million  to  340  million  depending  upon  the  assumptions  used  in  the 
estimate. 
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CAP  Objectives 

A)  Contain  GMPOX  to  Despotistan  until  the  epidemic  burns  itself  out,  with  UN 
approval  to. 

1 )  Support  NGO  medical  teams  to  contain  the  GMPOX  epidemic  within 
Despotistan. 

2)  Insert  NGO  or  military  medical  teams  into  Despotistan  to  perform  ring- 
vaccination  containment  of  the  GMPOX  epidemic  to  urban  areas,  with 
or  without  Government  approval. 

3)  Prevent  by  blockade  and  civil  travel  bans,  travel  out  of  the  afflicted 
regions. 

4)  Maintain  a  reserve  rapid  response  capability  to  perform  ring- 
vaccination  and  diagnostics  of  suspected  cases  of  GMPOX  outside  of 
Despotistan. 

B)  Sequal: 

1 )  Support  Despotistan  in  performing  decontamination  of  urban  areas  after 
containment. 

C)  Branch: 

1 )  In  order  to  stave  of  a  pandemic,  former  Soviet  and  Western  forces 
have  agreed  to  cooperate  in  sterilizing  afflicted  regions  using  appropriate 
weapons  if  containment  proves  ineffective. 

IO  /  Assessment  plan 

Operation  Healing  Voice  (10  support  to  CAP): 

Operation  Level  Indicator  (evaluate  for  direction  and  magnitude): 

—  Despotistan  public  announcements  on  5  national  broadcast  channels 

supporting  western  NGO  and  military  support  teams  entering  the  country 

and  encouraging  assistance.  Expected  magnitude  is  all  five  channels, 

repeated  every  hour. 


1)  Operational  Objective:  Western  public  is  informed  of  the  risk  of  travel  by 
personal  from  the  plague  area,  and  military  &  NGO  efforts  to  contain  the 
disease,  without  inducing  panic  (Public  Affairs  activity). 

a.  Objective  level  Indicators: 

i.  Polling  indicating  understanding  of  what-to-look-for,  what-to- 
do  in  targeted  areas  (evaluate  for  direction,  i.e.,  correct 
understanding,  and  magnitude).  Expected  magnitude  is  * 
25%  of  population. 

b.  Tactical  Objective 

i.  Provide  official  news  releases  &  PSAs  (Public  Affairs 
activity). 

1 .  Indicators  (evaluate  for  both  direction  and  magnitude) 
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a.  Accurate,  non-sensational  stories  appearing  on 
US  broadcast,  CNN,  BBC,  Fox,  and  SkyNews. 

b.  Accurate,  non-sensational  stories  appearing  in 
print  media  (including  mainstream  electronic 
print  media) 

ii.  Provide  experts  for  background  and  on-air  interviews  to 
counter  misconceptions  (Public  Affairs  activity). 

1 .  Indicators  (evaluate  for  both  direction  and  magnitude) 
a.  Accurate  interviews  US  broadcast,  CNN,  BBC, 
Fox,  and  SkyNews 

2)  Operational  Objective:  Agraria  civilian  medical  authorities  are  informed  of 
the  need  to  accurately  isolate  and  report  new  cases  through  military 
channels. 

a.  Indicators  (Evaluate  for  Direction  and  Magnitude  based  on  all 
clinics  reporting  daily) 

i.  False-alarm  reports  (Chicken-pox  &  other  benign  rashes)  are 
traced  to  facilities/physicians  who  have  not  received 
diagnostic  guides. 

b.  Tactical  Objective 

i.  Translate  and  distribute  differential  diagnosis  and  reporting 
guides  to  1800  physicians,  124  clinics  and  3  hospitals  in 
targeted  Agraria  areas. 

1 .  Tactical  Task:  Distribute  to  200  physicians  in  border 
region. 

a.  Magnitude  Indicators 

i.  Polling  indicates  >100%  availability  of 
diagnostic  and  reporting  guides  in 
medical  facilities  in  Agraria  border 
regions. 

b.  Direction  Indicators 

i.  Medical  education  teams  assess 
understanding  and  application  of 
materials. 

2.  Tactical  Task:  Distribute  to  1600  physicians  in 
balance  of  Agraria. 

a.  Magnitude  Indicators 

i.  Polling  indicates  >80%  availability  of 
diagnostic  and  reporting  guides  in 
medical  facilities  in  Agraria. 

b.  Direction  Indicators 

i.  Medical  education  teams  assess 
understanding  and  application  of 
materials. 
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3)  Operational  Objective:  Despotistan  government  officials  at  national, 
regional  and  local  levels  are  apprised  of  United  Nations  intent  to  insert 
medical  teams,  urged  to  cooperate  to  achieve  containment,  and  warned  of 
the  certain  consequences  of  containment  failure. 

a.  Indicators 

i.  NGO  teams,  with  Western  military  security  and  logistics,  are 
unchallenged  by  organized  military  or  police  resistance  in 
effecting  ring  vaccination  (Direction  only). 

ii.  Public  Despotistan  broadcasts  urging  cooperation  with 
Western  NGO  and  military  teams  are  detected  (Evaluate  for 
direction  &  magnitude  (24  million/5  channels) 

iii.  All  five  Despotistan  heavy  brigades  return/remain  in  garrison 
(Direction  &  Magnitude) 

b.  Tactical  Objective:  Influence  National  leadership  (key  3  Generals) 

i.  Tactical  Task:  Direct  telephone  contact 

1 .  Indicators  (evaluate  for  magnitude  &  direction) 

a.  Dialog  established  with  5  key  national  leaders 
(24  million  total  population) 

ii.  Tactical  Task:  Direct  email  contact 

1 .  Indicators  (evaluate  for  magnitude  &  direction) 

a.  Dialog  established  with  5  key  national  leaders 
(24  million  total  population) 

c.  Tactical  Objective:  Influence  Provincial  leadership  (24  military 
governors) 

i.  Tactical  Task:  Direct  telephone  contact 

1 .  Indicators  (evaluate  for  magnitude  &  direction) 

a.  Dialog  established  with  24  military  governors 
(24  million  total  population) 

ii.  Tactical  Task:  Direct  email  contact 

1 .  Indicators  (evaluate  for  magnitude  &  direction) 

a.  Dialog  established  with  24  military  governors 
(24  million  total  population) 

d.  Tactical  Objective:  Influence  local  urban  leadership  (city  mayors, 
police  chiefs,  12  total) 

i.  Tactical  Task:  Direct  telephone  contact 

1 .  Indicators  (evaluate  for  magnitude  &  direction) 
a.  Dialog  established  with  12  local  leaders 

ii.  Tactical  Task:  Direct  email  contact 

1 .  Indicators  (evaluate  for  magnitude  &  direction) 
a.  Dialog  established  with  12  local  leaders 

e.  Tactical  Objective:  Open  national  firewall  to  allow  outside  contact 
from  selected  sources 

i.  Tactical  Task:  Open  Internet  firewall 

1 .  Duration  Indicators  (3  to  21  days  desired) 
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a.  Firewall  opening  remains  for  standard 
maintenance  cycle  length  of  seven  days. 

2.  Degree  indicators  (75  to  100%  selected  servers 
desired) 

a.  Ping  response  on  previously  blocked  ports  on 
selected  servers  indicating  reduction  in  firewall 
effectiveness. 

3.  Collateral  Duration  Indicators:  On  detection  of 
breach,  firewall  is  locked  down,  typically  in  <  12 
hours. 

4.  Collateral  Degree  Indicators:  Loss  of  contact  to  > 
10%  of  normally  opened  ports 

Tactical  Task:  Open  telecomm  firewall 

1 .  Duration  Indicators  (3  to  21  days  desired) 

a.  Firewall  opening  remains  for  standard 
maintenance  cycle  length  of  seven  days. 

2.  Degree  indicators  (75  to  100%  selected  switches 
desired) 

a.  Connection  response  on  selected  switches 
indicating  reduction  in  firewall  effectiveness. 

3.  Collateral  Duration  Indicators:  On  detection  of 
breach,  firewall  is  locked  down,  typically  in  <  12 
hours. 

4.  Collateral  Degree  Indicators:  Loss  of  contact  to  > 
10%  of  normally  opened  ports 
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10.0  XML  Plan  File  for  Operation  Healing  Voice  Scenario 

The  following  is  the  plan  file  for  Operation  Healing  Voice  scenario  in  XML  format. 
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<node  ID="1"  infopType="P"  desc="Operation  Healing  Voice" 

longDesc="IO  support  to  contain  GM  smallpox  to  Despotistan" 
baseMag="24000000"  indWeight=" . 3"  weight="l"  weightLock=" "  conf idence=" . 4 " 
age="99999"  ass="N"> 

<dirindis> 

<item  ID="63"  parentID="l"  indiType="Dir"  desired="true"  desc="Chan  A  Public 
broadcast  analysis" 

longDesc=" Inf luence  Analysis  Report  on  Despotistan  public  broadcast  of 
Channel  A  supporting  western  NGO  and  military  support  teams  entering  the  country. " 

weight=" . 334 "  weightLock=" false"  conf idence=" . 5 "  age="l"  ass="F" 
assVal=" . 7"/> 

<item  ID="64"  parentID="l"  indiType="Dir "  desired="true"  desc="Chan  B  Public 
broadcast  analysis" 

longDesc=" Inf luence  Analysis  Report  on  Despotistan  public  broadcast  of 
Channel  B  supporting  western  NGO  and  military  support  teams  entering  the  country. " 

weight=" . 333 "  weightLock=" false"  conf idence=" . 3 "  age="l" 
ass="F"assVal=" . 3"/> 

<item  ID="65"  parentID="l"  indiType="Dir "  desired="true"  desc="Chan  C,D,E  Public 
broadcast  analysis" 

longDesc=" Inf luence  Analysis  Report  on  Despotistan  public  broadcast  of 
Channels  C,D,  and  E  (combined)  supporting  western  NGO  and  military  support  teams 
entering  the  country." 

weight=" . 333 "  weightLock=" false"  conf idence=" . 6 "  age="3"  ass="F" 
assVal=" . 5"/> 

</dirindis> 

<magindis> 

<item  ID="66"  parentID="l"  indiType="Mag"  desired="true"  desc="Chan  A  viewership 

size" 

longDesc="Despotistan  public  broadcast  Channel  A  viewership  size 

estimate . " 

weight="0 . 334"  weightLock="false"  confidence=" . 5"  age="5"  ass="U" 
assVal="5000000"/> 

<item  ID="67"  parentID="l"  indiType="Mag"  desired="true"  desc="Chan  B  viewership 

size" 

longDesc="Despotistan  public  broadcast  Channel  B  viewership  size 

estimate . " 

weight="0 . 333"  weightLock="false"  confidence=" . 5"  age="5"  ass="U" 
assVal="2000000"/> 

<item  ID="68"  parentID="l"  indiType="Mag"  desired="true"  desc="Chan  C,D,E 
viewership  size" 

longDesc="Despotistan  public  broadcast  Channel  C, D,  and  E  combined 
viewership  size  estimate." 

weight="0 . 333"  weightLock="false"  confidence=" . 8"  age="5"  ass="U" 
assVal="1000000"/> 

</magindis> 

<node  ID="2"  parentID="l"  infopType="P"  desc="001 :  (PA) Inform  Western  Public" 

longDesc="Western  public  is  informed  of  the  risk  of  travel  by  personal  from 
the  plague  area,  and  military  and  NGO  efforts  to  contain  the  disease,  without  inducing 
panic . " 

baseMag="50000000"  indWeight=" . 1"  weight=".15"  weightLock="false" 
confidence="0"  age="99999"  ass="N"  > 

<dirindis> 

<item  ID="22"  parentID="2"  indiType="Dir "  desired="true"  desc="What-To-Do 
Poll  Results" 

longDesc="Polling  results  need  to  indicate  understanding  of  what-to- 
look-for,  what-to-do  in  targeted  areas." 

weight="1.0"  weightLock="false"  confidence=" . 9"  age="0"  ass="F" 

assVal=" . 8"/> 

</dirindis> 

<magindis> 

<item  ID="23"  parentID="2"  indiType="Mag"  desired="true"  desc="Phone  Poll 
favorable  response  ratio" 
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weight="0.8"  weightLock=" false"  conf idence=" . 75"  age="0"  ass="F" 
as sVal=" 45000000 "/> 

<item  ID="24"  parentID="2"  indiType="Mag"  desired="true"  desc="Street  Poll 
favorable  response  ratio" 

weight="0.2"  weightLock=" false"  conf idence=" . 8 "  age="l"  ass="A" 
assVal="18000000"/> 

</magindis> 

<node  ID="5"  parentID="2"  infopType="I "  desc="TTlA:  News  releases  and  PSAs" 
longDesc="Provide  official  news  releases  and  PSAs." 
baseMag="150000000"  indWeight="l"  weight=".35"  weightLock="false" 
confidence="0"  age="99999"  ass="N"> 

<dirindis> 

<item  ID="25"  parentID="5"  indiType="Dir"  desired="true"  desc="TV  News 

Analysis " 

longDesc="Accurate,  non-sensational  stories  appearing  on  US 
broadcast,  CNN,  BBC,  Fox,  and  SkyNews." 

weight="0.7"  weightLock="false"  confidence=" . 6"  age="0"  ass="F" 

assVal=" . 8"/> 

<item  ID="26"  parentID="5"  indiType=" Dir "  desired="true"  desc="Print  News 

Analysis " 

longDesc="Accurate,  non-sensational  stories  appearing  in  print  media 
(including  mainstream  electronic)." 

weight="0.3"  weightLock="false"  confidence=" . 8"  age="0"  ass="F" 

assVal=" . 9"/> 

</dirindis> 

<magindis> 

<item  ID="27"  parentID="5"  indiType="Mag"  desired="true"  desc="TV  News 
audience  size" 

longDesc="US  broadcast  viewership  size--CNN,  BBC,  Fox,  and  SkyNews 

combined . " 

weight="0.7"  weightLock="false"  confidence=" . 9"  age="5"  ass="U" 

assVal=" 6000000"/> 

<item  ID="28"  parentID="5"  indiType="Mag"  desired="true"  desc="Print  News 
audience  size" 

longDesc="Source  print  media  (including  mainstream  electronic) 

distrubtion  size." 

weight="0.3"  weightLock="false"  confidence=" . 7"  age="5"  ass="U" 

assVal="1800000"/> 

</magindis> 

</ node> 

<node  ID="6"  parentID="2"  infopType="I "  desc="TTlB:  Expert  Interviews" 

longDesc="Provide  experts  for  background  and  on-air  interviews  to  counter 
misconceptions  .  " 

baseMag="35000000"  indWeight="l"  weight=".35"  weightLock="false" 
confidence="0"  age="0"  ass="N"> 

<dirindis> 

<item  ID="29"  parentID="6"  indiType="Dir"  desired="true"  desc=" Interview 
Assessment"  weight="1.0"  weightLock="false"  confidence=" . 75"  age="0"  ass="F" 
assVal=" . 9"/> 

</dirindis> 

<magindis> 

<item  ID="30"  parentID="6"  indiType="Mag"  desired="true"  desc=" Interview 
Audience"  weight="1.0"  weightLock="false"  confidence=" . 9"  age="0"  ass="A" 
assVal="15000000"/> 

</magindis> 

</ node> 

</node> 

<node  ID="3"  parentID="l"  infopType="P"  desc="002:  Disseminate  diagnostic/reporting 
info" 

longDesc="Agraria  civilian  medical  authorities  are  informed  of  the  need  to 
accurately  isolate  and  report  new  cases  through  military  channels." 

baseMag="2000"  indWeight=" . 2"  weight=".25"  weightLock="false"  confidence="0" 
age="99999"  ass="N"> 


A-59 


<dirindis> 

<item  ID="31"  parentID="3"  indiType="Dir "  desired="true"  desc="NGO  reports 
diagnosic  guides  in  use"  weight="1.0"  weightLock="f alse"  confidence="0"  age="3" 
ass="A"  assVal=" . l"/> 

</ dirindis> 

<magindis> 

<item  ID="32"  parentID="3"  indiType="Mag"  desired="true"  desc="Percent  false- 
alarms  trace  to  lack  of  diag  guide  "  weight="1.0"  weightLock="false"  confidence=" . 5" 
age="3"  ass="U"  assVal=  "400"/> 

</magindis> 

<node  ID="7"  parentID="3"  infopType="P"  desc="T02A:  Distribute  info  to  Agraria  " 
longDesc="Translate  and  distribute  differential  diagnosis  and  reporting 
guides  to  1800  physicians  in  targeted  Agraria  areas." 

baseMag="1800"  indWeight="0"  weight=".6"  weightLock="false"  confidence="0" 
age="99999"  ass="N"> 

<dirindis/> 

<magindis/> 

<node  ID="12"  parentID="7"  infopType=" I "  desc="TT2Al :  Distribute  to  Agraria 
border  regions" 

longDesc="Distr ibute  to  200  physicians  in  border  region." 

baseMag="200"  indWeight="l"  weight=".4"  weightLock="false" 
confidence="0"  age="99999"  ass="N"> 

<dirindis> 

<item  ID="34"  parentID="12"  indiType="Dir"  desired="true"  desc="Med  Ed 
Team  Assessments"  weight="1.0"  weightLock="false"  confidence=" . 5"  age="99999"  ass="U" 
assVal="-0 . 8 "/> 

</ dirindis> 

<magindis> 

<item  ID="35"  parentID="12"  indiType="Mag"  desired="true" 
desc="Physicians  confirming  recipt"  weight="1.0"  weightLock=" false"  confidence=" . 3" 
age="3"  ass="F"  assVal="180"/> 

</magindis> 

</node> 

<node  ID="13"  parentID="7"  infopType=" I "  desc="TT2A2 :  Distribute  to  Agraria" 

longDesc="Distribute  to  1600  physicians,  90  clinics,  and  2  hospitals  in 
balance  of  Agraria." 

baseMag="1800"  indWeight="l "  weight=".4"  weightLock="false" 
confidence="0"  age="99999"  ass="N"> 

<dirindis> 

<item  ID="36"  parentID="13"  indiType="Dir"  desired="true"  desc="Med  Ed 
Team  Assessments"  weight="1.0"  weightLock="false"  confidence=" . 7"  age="99999"  ass="A" 
assVal="-0 . 2 "/> 

</ dirindis> 

<magindis> 

<item  ID="37"  parentID="13"  indiType="Mag"  desired="true"  desc="Agraria 
Polling"  weight="1.0"  weightLock=" false"  conf idence=" . 5 "  age="99999"  ass="U" 
assVal="500"/> 

</magindis> 

</node> 

</node> 

</node> 

<node  id="4"  parentID="l"  infopType="P"  desc="003:  Despotistan  Gov  Warned" 

longDesc="Despotistan  government  officials  at  national,  regional  and  local 
levels  are  apprised  of  United  Nations  intent  to  insert  medical  teams,  urged  to 
cooperate  to  achieve  containment,  and  warned  of  the  certain  consequences  of 
containment  failure." 

baseMag="24000000"  indWeight=" . 3"  weight=".35"  weightLock="false" 
confidence="0"  age="99999"  ass="N"> 

<dirindis> 

<item  ID="38"  parentID="4"  indiType="Dir "  desired="true"  desc="NGO  Team 
access"  weight=".4"  weightLock="false"  confidence=" . 1 "  age="2"  ass="A"  assVal="0"/> 
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<item  ID="39"  parentID="4"  indiType="Dir "  desired="true"  desc="Cooperation 
Broadcasts  detected"  weight=".3"  weightLock="false"  confidence=" . 5"  age="2"  ass="A" 
assVal="0 . 2"/> 

<item  ID="40"  parentID="4"  indiType="Dir "  desired="true"  desc="Brigades 
withdraw  from  border"  weight=".3"  weightLock="false"  conf idence=" 1 . 0"  age="l"  ass="F" 
assVal="l . 0"/> 

</dirindis> 

<magindis> 

<item  ID="41"  parentID="4"  indiType="Mag"  desired="true"  desc="Broadcast 
channels  used"  weight="0.5"  weightLock="false"  confidence="0"  age="l"  ass="U" 
assVal="5000000"/> 

<item  ID="42"  parentID="4"  indiType="Mag"  desired="true"  desc="Brigades  in 
garrison"  weight="0.5"  weightLock="false"  confidence="0"  age="3"  ass="A" 
assVal="15000000"/> 

</magindis> 

<node  ID="8"  parentID="4"  infopType="P"  desc="T03A:  Dialog  Despotistan  national 
leadership" 

longDesc=" Inf luence  National  leadership  (key  5  Generals)." 
baseMag="5"  indWeight="0"  weight=".2"  weightLock="false"  confidence="0" 
age="99999"  ass="N"> 

<dirindis/> 

<magindis/> 

<node  ID="14"  parentID="8"  infopType=" I "  desc="TT3Al :  Direct  telephone 

contact" 

baseMag="5"  indWeight="l"  weight=".5"  weightLock="false"  confidence="0" 
age="99999"  ass="N"> 

<dirindis> 

<item  ID="43"  parentID="14"  indiType="Dir"  desired="true"  desc="Dialogs 
established  w/  leaders"  weight="1.0"  weightLock="false"  confidence=" . 5"  age="l" 
ass="F"  assVal=" . 7"/> 

</ dirindis> 

<magindis> 

<item  ID="44"  parentID="14"  indiType="Mag"  desired="true"  desc="Numbe 
of  leaders"  weight="1.0"  weightLock="false"  confidence=" . 9"  age="l"  ass="F" 
assVal="4"/> 

</magindis> 

</node> 

<node  ID="15"  parentID="8"  infopType=" I "  desc="TT3A2 :  Direct  email  contact" 
baseMag="5"  indWeight="l"  weight=".5"  weightLock="false"  confidence="0"  age="99999" 
ass="N"> 

<dirindis> 

<item  ID="45"  parentID="15"  indiType="Dir"  desired="true"  desc="Dialogs 
established  w/  leaders"  weight="1.0"  weightLock="false"  confidence=" . 7"  age="l" 
ass="A"  assVal=" ,2"/> 

</ dirindis> 

<magindis> 

<item  ID="46"  parentID="15"  indiType="Mag"  desired="true"  desc="Numbe 
of  leaders"  weight="1.0"  weightLock="false"  confidence=" . 9"  age="l"  ass="U" 
assVal="2"/> 

</magindis> 

</node> 

</ node> 

<node  ID="9"  parentID="4"  infopType="P"  desc="T03B:  Dialog  Despotistan 
provincial  leadership" 

longDesc=" Inf luence  Provincial  leadership  (24  military  governors)." 
baseMag="24"  indWeight="0"  weight=".2"  weightLock="false"  confidence="0" 
age="99999"  ass="N"> 

<dirindis/> 

<magindis/> 

<node  ID="16"  parentID="9"  infopType=" I "  desc="TT3Bl :  Direct  telephone 
contact"  baseMag="24"  indWeight="l"  weight=".5"  weightLock="false"  confidence="0" 
age="99999"  ass="N"> 

<dirindis> 
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<item  ID="47"  parentID=" 1 6"  indiType="Dir"  desired="true"  desc="Dialogs 
established  w/  leaders"  weight="1.0"  weightLock="false"  confidence=" . 5"  age="l" 
ass="F"  assVal=" . 8 "/> 

</ dirindis> 

<magindis> 

<item  ID="48"  parentID=" 1 6"  indiType="Mag"  desired="true"  desc="Numbe 
of  leaders"  weight="1.0"  weightLock="false"  confidence=" . 9"  age="l"  ass="F" 
assVal="18"/> 

</magindis> 

</node> 

<node  ID="17"  parentID="9"  infopType=" I "  desc="TT3B2 :  Direct  email  contact" 
baseMag="24000000"  indWeight="l"  weight=".5"  weightLock=" false"  confidence="0" 
age="99999"  ass="N"> 

<dirindis> 

<item  ID="49"  parentID="17"  indiType="Dir"  desired="true"  desc="Dialogs 
established  w/  leaders"  weight="1.0"  weightLock="false"  confidence=" . 5"  age="l" 
ass="A"  assVal=" . 5"/> 

</ dirindis> 

<magindis> 

<item  ID="50"  parentID="17"  indiType="Mag"  desired="true"  desc="Numbe 
of  leaders"  weight="1.0"  weightLock="false"  confidence=" . 7"  age="3"  ass="U" 
assVal="8"/> 

</magindis> 

</node> 

</node> 

<node  ID="10"  parentID="4"  infopType="P"  desc="T03C:  Dialog  Despotistan  local 
leadership" 

longDesc=" Inf luence  local  leadership  (village/city  mayors,  police 

chiefs ) . " 

baseMag="12"  indWeight="0"  weight=".2"  weightLock="false"  confidence="0" 
age="99999"  ass="N"> 

<dirindis/> 

<magindis/> 

<node  ID="18"  parentID="10"  infopType="I "  desc="TT3Cl:  Direct  telephone 
contact"  baseMag="12"  indWeight="l"  weight=".5"  weightLock="false"  confidence="0" 
age="99999"  ass="N"> 

<dirindis> 

<item  ID="51"  parentID="18"  indiType="Dir"  desired="true"  desc="Dialogs 
established  w/  local  leaders"  weight="1.0"  weightLock="false"  confidence="0"  age="6" 
ass="A"  assVal=" . l"/> 

</ dirindis> 

<magindis> 

<item  ID="52"  parentID="18"  indiType="Mag"  desired="true"  desc="Number 
of  leaders"  weight="1.0"  weightLock="false"  confidence="0"  age="3"  ass="A" 
assVal="7"/> 

</magindis> 

</node> 

<node  ID="19"  parentID="10"  infopType="I "  desc="TT3C2:  Direct  email  contact" 
baseMag="12"  indWeight="l"  weight=".5"  weightLock="false"  confidence="0"  age="99999" 
ass="N"> 

<dirindis> 

<item  ID="53"  parentID=" 1 9"  indiType="Dir"  desired="true"  desc="Dialogs 
established  w/  local  leaders"  weight="1.0"  weightLock="false"  confidence=" . 5"  age="2" 
ass="F"  assVal=" . 5"/> 

</ dirindis> 

<magindis> 

<item  ID="54"  parentID=" 1 9"  indiType="Mag"  desired="true"  desc="Numbe 
of  leaders"  weight="1.0"  weightLock="false"  confidence=" . 9"  age="2"  ass="F" 
assVal="12"/> 

</magindis> 

</node> 

</node> 

<node  ID— "11"  parentID="4"  infopType="P"  desc="T03D:  Open  national  fireall" 
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longDesc="Open  national  firewall  to  allow  outside  contact  from  selected 

sources . " 

baseMag="24000000"  indWeight="0"  weight=".2"  weightLock="false" 
confidence="0"  age="99999"  ass="N"> 

<dirindis/> 

<magindis/> 

<node  ID="20"  parentID="ll"  inf opType="A"  desc="TT3Dl:  Open  internet 
firewall"  baseMag="24000000"  indWeight=" 1 "  weight=".5"  weightLock=" false" 
confidence="0"  age="99999"  ass="N"> 

<thresholds  desduraccmin="172800"  desdurfavmin="259200" 
desdurfavmax="1814400"  desduraccmax="2505600"  descapaccmin="60"  descapfavmin="75" 
descapfavmax="100"  descapaccmax="100"  coldurfavmin="0"  coldurfavmax="0" 
colduraccmin="0"  colduraccmax="43200"  colcapfavmin="0"  colcapfavmax="0" 
colcapaccmin=" 0"  colcapaccmax="l 0" /> 

<ddurindis> 

<item  ID="55"  parentID="20"  indiType="Dur"  desired="true" 
desc="Firewall  Maintenance  cycle  length"  weight="1.0"  weightLock="false" 
confidence="0"  age="99999"  ass="N"/> 

</ ddurindis> 

<dcapindis> 

<item  ID="56"  parentID="20"  indiType="CapRedux"  desired="true" 
desc="Reduction  in  blocked  desired  ports/servers"  weight="1.0"  weightLock=" false" 
confidence="0"  age="99999"  ass="N"/> 

</ dcapindis> 

<cdurindis> 

<item  ID="57"  parentID="20"  indiType=" Dur "  desired="true" 
desc="Detected  breach  shutdown,  out  of  cycle  maint"  weight="1.0"  weightLock="false" 
confidence="0"  age="99999"  ass="N"/> 

</ cdurindis> 

<ccapindis> 

<item  ID="58"  parentID="20"  indiType="CapRedux"  desired="true" 
desc="Additional  ports/servers  blocked"  weight="1.0"  weightLock=" false"  confidence="0" 
age="99999"  ass="N"/> 

</ ccapindis> 

</node> 

<node  ID="21"  parentID="ll"  inf opType="A"  desc="TT3D2:  Open  telecom  firewall" 
baseMag="24000000"  indWeight="l"  weight=".5"  weightLock=" false"  confidence="0" 
age="99999"  ass="N"> 

<thresholds  desduraccmin="172800"  desdurfavmin="259200" 
desdurfavmax="1814400"  desduraccmax="2505600"  descapaccmin="60"  descapfavmin="75" 
descapfavmax="100"  descapaccmax="100"  coldurfavmin="0"  coldurfavmax="0" 
colduraccmin="0"  colduraccmax="43200"  colcapfavmin="0"  colcapfavmax="0" 
colcapaccmin=" 0"  colcapaccmax="l 0" /> 

<ddurindis> 

<item  ID="59"  parentID="21"  indiType="Dur"  desired="true" 
desc="Firewall  Maintenance  cycle  length"  weight="1.0"  weightLock="false" 
confidence="0"  age="99999"  ass="A"  assVal="432000"/> 

</ ddurindis> 

<dcapindis> 

<item  ID="60"  parentID="21"  indiType="CapRedux"  desired="true" 
desc="Reduction  in  blocked  desired  telcom  switches"  weight="1.0"  weightLock="false" 
confidence="0"  age="3"  ass="A"  assVal="89"/> 

</ dcapindis> 

<cdurindis> 

<item  ID="61"  parentID="21"  indiType="Dur"  desired="true" 
desc="Detected  breach  shutdown,  out  of  cycle  maint"  weight="1.0"  weightLock="false" 
conf idence=" . 5 "  age="2"  ass="F"  assVal="0 . 0"/> 

</ cdurindis> 

<ccapindis> 

<item  ID="62"  parentID="21"  indiType="CapRedux"  desired="true" 
desc="Additional  switches  blocked"  weight="1.0"  weightLock="false"  confidence=" . 5" 
age="3"  ass="F"  assVal="0 . 0"/> 

</ ccapindis> 


A-63 


</node> 
</ node> 
</node> 

</ node> 
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Introduction 

This  final  r  eport  w  ill  give  an  ov  erview  of  t  he  w  ork  ac  complished  by  t  he  S  RA  T  eneo 
team.  This  report  will  include  the  initial  feature  set,  appeal,  and  drawbacks  of  the  Teneo 
software.  A  II  w  ork  per  formed  by  S  RA  i  s  al  so  d  ocumented  here.  F  inally, 
recommendations  on  how  to  proceed  are  discussed. 

Teneo  Software  Overview 

Major  Features 

In  analyzing  the  software,  the  source  code,  and  the  available  documentation,  the  major 
functional  features  o f  Teneo  hav e  b  een  i  dentified.  P  lease  r efer  t o  F  igure  1 ,  “Teneo 
Screenshot”,  for  a  visual  depiction  of  the  features. 
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Figure  1:  Teneo  Screenshot 


A  map  view  with  a  customizable  background  is  used  to  display  targets,  weapons,  and 
Air  Tasking  Order  (ATO)  nodes.  The  different  categories  of  items  that  are  displayed  are 
separated  into  layers  that  can  be  toggled  on  or  off.  Each  layer  contains  a  collection  of 
nodes  an  d  eac h  no de  c ontains  detailed  i  nformation  t hat  can  b e  q  uickly  s hown  t o  t he 
user.  If  the  node  is  a  ranged  weapon  or  a  missile  site,  it  will  have  a  circle  drawn  around 
it  that  indicates  its  range.  At  any  point,  a  snapshot  of  the  map  shown  on  the  screen  can 
be  saved  to  a  JPEG  picture  file. 
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A  timeline,  in  the  form  of  a  Gantt  chart,  shows  the  period  of  activity  of  the  ATO  and 
weapons  systems.  T  his  t  imeline  i  s  di  splayed  i  n  c  lose  pr  oximity  of  t  he  map  v  iew.  A 
scenario  playback  feature  can  be  used  to  show  the  advancement  of  time  through  the 
timeline.  A  ‘current  time’  marker  on  the  timeline  shows  the  state  of  the  scenario  in  hourly 
intervals.  When  a  weapon  system  is  active  at  the  time  indicated  by  this  marker,  its  entry 
on  t  he  t  imeline  i  s  hi  ghlighted.  A  Iso,  i  f  i  t  i  s  a  r  anged  weapon,  t  he  s  urrounding  r  ing 
depicting  the  weapon’s  range  becomes  visible.  Any  target  nodes  that  are  affected  by 
any  active  weapon  are  highlighted  on  the  map  and  listed  in  a  grid  view. 

Layer  dat  a  c  an  be  i  imported  from  ou  tside  dat  a  s  ources.  A  TO  target  dat  a  c  an  b  e 
imported  from  United  States  Message  Text  Format  (USMTF)  files.  General  layer  data 
can  be  imported  from  Links  and  Nodes  (“.In”)  files. 

Teneo  also  includes  an  ATO  viewer.  This  can  be  used  to  view  any  ATO  entries  in  the 
current  scenario  or  to  preview  an  ATO  that  is  stored  in  a  file.  The  ATO  is  organized  into 
four  customizable  grids:  ‘Ground  targets,’  ‘Aircraft,’  ’  Missile  targets,’  and  ‘  Units.’  T  he 
grid  can  be  successively  grouped  by  any  field  in  the  ATO.  It  can  also  be  sorted  by  any 
field. 

Teneo’s  Appeal 

Teneo’s  ov  erall  c  oncept  w  as  w  ell  r  eceived  by  t  he  user  c  ommunity.  I  n  par  ticular, 
scenario  playback  and  a  temporal  synchronization  display  in  the  form  of  a  G  antt  chart 
were  identified  as  useful  features.  Also,  having  a  selectable  background  allows  the  user 
to  customize  the  view  to  suit  their  particular  needs,  and  the  detailed  display  of  object 
(node)  data  gives  easy  access  to  a  greater  depth  of  information. 

From  a  more  technical  perspective,  USMTF  support  and  the  ATO  grid  are  valuable 
assets.  The  ability  t  o  i  mport  di  rectly  f  rom  U  SMTF  t  ext  f  ormat  al  lows  f  or  s  tandard 
information  exchange  with  other  systems  and  the  grid  control  is  easy  to  use  and  excels 
at  sorting/grouping  this  type  of  tabular  data. 

Identified  Issues/Drawbacks 

While  t  he  c  oncept  t  hat  T  eneo  pr  esents  i  s  excellent,  t  he  i  mplementation  h  as  a  I  ot  of 
problems.  The  reason  for  this  is  that  Teneo  was  meant  to  be  a  prototype  not  intended 
for  release.  It  was  developed  very  quickly  for  a  specific  audience  and,  as  such,  makes 
many  assumptions.  These  assumptions  preclude  any  error  handling  or  concern  for  what 
a  g  eneric  us  er  may  w  ant.  E  rrors  ar  e  g  enerally  handl  ed  by  f  ailing  and  ex  iting  t  he 
program .  Asa  prototype,  c  ode  c  omments  a  re  nei  ther  pr  esent  nor  ex  pected  a  nd  t  he 
provided  doc  umentation  r  eflects  t  he  c  oncepts  o  f  el  ectronic  w  arfare  ( EW),  r  ather  t  han 
providing  insight  into  the  software. 

The  code  is  not  modular  and  is,  in  general,  very  fragile  and  inflexible.  Because  of  this, 
the  software  is  very  resistant  to  modification,  as  mild  changes  can  have  catastrophic 
effects.  T  he  I  ack  of  modularity  c  reates  s  ome  c  onfusing  i  nterdependencies  between 
seemingly  unrelated  source  files.  Even  moderate  tasks  (in  either  using  the  software  or 
changing  the  code)  become  exceedingly  difficult  due  to  the  design  of  the  system. 
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Hard  c  oded  v  alues  i  n  t  he  s  ource  c  ode  make  t  he  final  s  oftware  di  fficult  t  o  us  e.  F  or 
example,  the  software  must  be  installed  to  ‘C:\Teneo’  with  the  data  directory  installed  to 
‘C:\TeneoTargetData’  or  m  any  t  hings  br  eak.  T  he  s  aved  s  cenarios  c  annot  be  e  asily 
transferred  to  another  machine,  or  even  another  directory,  easily.  This  is  because  the 
scenario  files  hav  e  I  inks  t  o  m  any  ot  her  f  iles  us  ing  abs  olute  p  aths.  U  nless  al  I  of  t  he 
referenced  files  are  i  n  ex  actly  t  he  s  ame  d  irectories  on  both  m  achines,  t  he  s  cenario 
cannot  be  read.  The  available  weapons  are  also  hard  coded,  so  no  new  weapons  can 
be  added  without  modification  of  the  source  code  (covered  in  the  previous  paragraph). 
The  effects  of  the  weapons  are  I  imited  to  layers,  rather  than  nodes.  For  example,  the 
‘R_Jammer’  weapon  affects  only  nodes  in  a  layer  specifically  called  ‘Nodes_Radar’.  If  a 
radar  site  were  located  on  another  layer,  the  R_Jammer  would  not  recognize  it. 

The  graphical  interface  is  not  fully  implemented.  The  user  can  do  many  things  that  the 
software  allows,  but  is  not  equipped  to  handle.  For  example,  trying  to  reorder  the  rows 
of  the  Gantt  chart  by  dragging  them  with  the  mouse  crashes  the  program.  The  windows 
are  not  designed  to  scale  well  and  lower  resolution  screens  are  not  shown  crucial  parts 
of  the  interface. 

It  should  also  be  n  oted  that  objects  do  not  move  during  animation  (planes,  etc).  The 
only  thing  that  moves  is  the  ‘current  time’  marker  on  the  Gantt  chart. 

The  t  echnology  behi  nd  t  he  m  ap  v  iew  i  s  E  SRI  (  Environmental  S  ystems  R  esearch 
Institute)  M  apObjects  2.  3,  w  hich  i  s  quite  old  and  i  s  bei  ng  pha  sed  out  i  n  favor  of 
ArcObjects.  ArcObjects  i  s  no  t  b  ackwards  c  ompatible  w  ith  MapObjects  a  nd  i  s 
considerably  more  expensive. 

Due  to  the  fact  that  Teneo  is  written  in  .NET  di  rectly  bonds  it  to  Microsoft  Windows 
machines  only,  immediately  eliminating  the  possibility  of  porting  the  software  to  other 
platforms,  such  as  Solaris. 


B-8 


SRA  Enhancements  to  Teneo 

SRA  incorporated  the  features  discussed  here  into  the  Teneo  prototype. 

Launch  Teneo  from  IWPC 

SRA  i  ntegrated  Teneo  t  o  I  aunch  from  t  he  I  nformation  Warfare  P  lanning  C  apability 
(IWPC)  main  menu.  This  involved  m inor  modifications  to  the  IWPC  source  code  and 
the  inclusion  of  a  new  source  file  in  the  IWPC  code  base. 

Functionality  was  al  so  add  ed  s  o  as  t  o  i  import  an  A  TO  di  rectly  f  rom  Theatre  B  attle 
Operations  Net-Centric  Environment  (TBONE)  using  a  web  services  interface. 

A  ‘wizard’  interface  was  added  to  Teneo  (accessible  from  the  ‘Import  Data’  menu),  that 
walks  t  he  us  er  t  hrough  i  mporting  an  A  TO  s  tored  i  n  TBONE.  T  he  us  er  en  ters  a 
username,  a  p  assword,  an d  a  date  range.  AnyATO  entries  that  start  or  end  i  n  the 
specified  date  range  are  returned  for  the  user  to  select. 

View  IWPC  Targets  In  Teneo 

SRA  enhanced  T  eneo  to  al  low  the  user  to  view  targets  from  IWPC  through  a  special 
layer  inside  Teneo.  The  client  is  setup  to  retrieve  any  targets  in  the  currently  viewable 
map  ar  ea  automatically.  These  t  argets  ar  e  r  etrieved  f  rom  a  web  s  ervice  on  t  he 
application  s  erver.  T  he  f  unctionality  t  o  pul  I  targets  f  rom  t  he  I WPC  dat  abase  a  nd  t  he 
Modernized  Integrated  Data  Base  (MIDB)  Data  Access  Layer  (MDAL)  was  developed. 
Final  i  ntegration  testing  ag  ainst  a  c  opy  o  f  the  M  IDB  w  as  not  performed  d  ue  t  o  t  he 
unavailability  of  a  copy  of  the  MIDB  to  SRA  at  the  time. 

Message  Passing  From  IWPC  Via  Pub-Sub  Web  Service 

SRA  c  reated  a  r  udimentary  publ  ish-subscribe  (  “pub-sub”)  framework  us  ing  w  eb 
services  i  n  or  der  t  o  f  acilitate  m  essage  pas  sing  f  rom  I  WPC.  T  his  publ  ish-subscribe 
framework  f  ollows  t  he  ev  ent  dr  iven  m  odel.  An  ev  ent  dr  iven  m  odel  i  s  pr  esent  w  hen 
changes  t  o  da  ta  by  any  c  lient  ar  e  t  hen  a  utomatically  r  eflected  in  al  I  ot  her  c  lients. 
Publish-Subscribe  ac  complishes  t  his  by  hav  ing  eac  h  c  lient  “  subscribe”  t  o  I  isten  f  or 
changes  to  data,  while  the  server  will  publish  all  changes  to  those  who  have  subscribed. 

This  framework  uses  web  service  based  registration  of  an  endpoint.  In  this  instance,  the 
endpoints  used  a  di  rect  s  ocket  c  onnection.  M  essages  c  an  be  targeted  a  t  s  pecific 
‘topics’  or  sent  as  broadcast  messages.  This  framework  was  intended  as  a  temporary 
implementation  that  would  fit  the  needs  of  the  project  and  should  not  be  considered  for 
a  production  level  environment. 

Target  Data  Retrieval  from  IWPC  and  MIDB 

SRA  created  a  web  service  to  allow  for  the  retrieval  of  target  data  from  IWPC  and  the 
MDAL/MIDB  based  on  a  user-defined  geographic  area  of  interest.  The  service  accepts 
latitude  and  longitude  coordinates  as  rectangular  bounds.  Any  targets  that  are  located 
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within  the  bounds  are  returned  in  a  list.  The  IWPC  database  and  the  MDAL/MIDB  are 
used  as  data  sources. 

ATO  Retrieval  Via  TBONE  .NET  Adapter 

SRA  developed  a  .NET  adapter  for  TBONE  to  enable  the  retrieval  of  ATOs  via  a  web 
service  i  nterface.  The  a  dapter  m  akes  both  c  ommunication  w  ith  T  BONE  a  nd 
manipulation  of  TBONE  data  easier. 

USMTF  Parser 

SRA  repaired  the  existing  USMTF  parser.  As  T eneo  was  originally  developed  for  the 
Korean  area  of  the  globe,  certain  assumptions  were  made  about  coordinate  data  and 
the  format  o  f  timestamps.  B  ecause  K  orea  i  s  I  ocated  i  n  t  he  first  q  uadrant  o  f  t  he 
coordinate  plane,  all  of  i  ts  c  oordinate  d  ata  w  ill  be  pos  itive  nu  mbers.  To  make  t  he 
importer  more  generic,  it  was  modified  to  expect  any  number. 

Architecture  View 


Figure  2:  Basic  Message  Passing  Structure. 


The  ‘Region  Service’  in  Figure  2,  “Basic  Message  Passing  Structure”,  is  the  service  that 
retrieves  t  argets  f  rom  t  he  I  WPC  d  atabase  and  M  DAL/MIDB  b  ased  on  a  g  eographic 
area.  The  ‘  SDS  E  xtension’ s  ervice  ac  ts  es  sentially  as  a  pas  s-through  t  o  t  he  r  egular 
Strategy  Development  Service  (SDS)  EJB  (Enterprise  Java  Bean). 

Any  links  connecting  to  the  pub-sub  service  are  using  the  custom  Publish-Subscribe 
implementation  created  by  SRA.  In  the  future,  a  standard  WS-Notification/WS-Eventing 
(or  ot  her  method)  ba  sed  s  olution  c  an  be  used.  At  t  his  t  ime,  n  o  w  eb  s  ervice  bas  ed 
approaches  are  usable.  The  IWPC  client’s  connection  to  this  web  service  was  planned, 
but  not  implemented  because  the  hour-by-hour  granularity  of  Teneo  does  not  fit  with  the 
day-by-day  approach  of  IWPC. 

Figure  3,  “Message  Passing  Sequence”,  shows  the  sequence  of  events  in  utilizing  the 
services  to  retrieve  a  list  of  targets  and  also  retrieving  an  ATO  from  IWPC/TBONE. 
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Figure  3:  Message  Passing  Sequence 
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Recommendations 

The  existing  implementation  can  be  us  ed  to  elicit  quick  user  feedback  that  will  reveal 
the  requirements  that  it  fulfills.  These  requirements  can  be  added  to  the  IOPC  effort. 

Due  to  the  EW  focus  of  Teneo,  a  f  unctional  comparison  and  o  perational  workflow 
analysis  should  be  performed  with  respect  to  Builder,  IMOM,  and  Dynamic  Course  of 
Action  Development  (DCOAD).  This  comparison  can  be  used  to  de-conflict  the  T eneo 
functionality  with  the  DCOAD  and  other  lab  functionality  being  developed. 

If  a  demonstrable  prototype  i  s  required  s  hort  term,  a  shift  in  technologies  should  be 
applied.  Using  the  completed  requirements  list,  moving  to  Java  and  BBN’s  OpenMap 
would  provide  a  number  of  advantages.  Using  Java  would  allow  for  easier  integration 
with  the  existing  tools  and  O  penMap  is  already  being  used  by  most  current  systems, 
providing  consistency  for  the  interface. 

If  a  prototype  is  not  required  short  term,  the  Teneo  feature  set  could  be  a  focus  of  future 
technology  prototyping. 

The  time  required  to  develop  a  stable  Java  +  OpenMap  implementation  is  estimated  at 
roughly  115  days,  including  95  days  to  stabilize  (re-engineer)  the  code  base,  with  all  of 
the  features  of  Teneo  as  it  was  delivered  to  SRA,  plus  another  20  days  to  add  in  the 
enhanced  connections  to  IWPC. 

IWPC/SDS  Integration  Analysis 

Current  IWPC  Architecture 

IWPC  i  s  c  urrently  I  aid  out  ar  ound  a  J  ava  2  E  nterprise  E  dition  (  J2EE)  f  at-client 
architecture  with  web  services  bolted  on.  There  is  nothing  intrinsically  wrong  with  IWPC 
using  t  he  faster,  more  r  eliable  J  ava  R  emote  M  ethod  I  nvocation  (  RMI)  pr  otocols  t  o 
access  t  he  s  erver,  bu  1 1  he  s  ame  functionality  s  hould  be  available  t  o  ot  her  us  ers  an  d 
applications  through  web  services  and  thin  web  applications. 
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As  noted  in  Figure  4,  “Current  IWPC  Fat-Client  and  J2EE  Server-Side  Applications”, 

IPS  serves  as  a  wrapper  for  a  number  of  other  services  within  IWPC,  these  being  as 
follows: 

•  IPS  -  Integrated  Planning  Service 

Wraps  other  service  implementations.  Strictly  call-through. 

•  SDS  -  Strategy  Development  Service 

View,  modify,  lock  and  delete  plan  elements. 

•  I  SVC  -  Intel  Service 

Searches  and  retrieves  data  from  MIDB. 

•  RFS/RFA  -  Request  for  Analysis  Service 

Make  and  view  requests,  communicate  results. 

•  PPS  -  Plan  Publication  Services 

Sends  plan  to  TBONE  in  Collaborative  Planning  Tool  (CPT)-XML  format. 

•  BCS  -  Briefing  Composer  Service 

Browses  database  of  briefing  templates  (based  of  off  source  code  analysis  and  not 
actual  documentation). 

So  far,  we  have  identified  SDS  and  ISVC  as  services  that  critically  need  to  be  updated 
for  TENEO  and  IOPC-X.  T  hese  two  services  provide  access  to  the  plan  (SDS)  and 
targets  associated  with  the  plan  (ISVC).  They  also  compose  the  bulk  of  the  methods  in 
IPS. 

Below,  we  analyze  the  current  state  of  the  IWPC  services  before  discussing  how  they 
may  be  improved. 

IPS 

The  IPS  web  service  deployment  does  not  work  at  all.  The  Axis  deployment  descriptor 
appears  to  be  duplicated  from  an  earlier  version  of  SDS.  It  is  pointed  at  the  wrong  Java 
implementation  class  and  attempting  to  browse  the  Web  Service  Description  Language 
(WSDL)  pag  ec  aused  A  xis  t  oc  rash  w  ith  a  c  lasspath  er  ror.  (  missing  i  18n 
(internationalization)  resource). 

SDS 

Unfortunately,  S  DS  ex  poses  t  he  I  WPC  B  aseEBOData  m  odel  di  rectly.  T  he 
BaseEBOData  model  has  a  number  of  methods  that  expose  the  raw  Java  Object  type. 
These  types  cannot  be  mapped  correctly  to  Simple  Object  Access  Protocol  (SOAP). 
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SDS  provides  limited  interoperability  even  if  the  configuration  problems  are  corrected.  It 
uses  an  A  xis  generated  WSDL.  These  WSDLs  are  never  fully  WS-I  compliant  (even 
when  Axis  is  using  Document-Literal  encoding).  SDS  is  deployed  at  /SDS_RC/services 
and  is  a  functional  part  of  the  IPSWeb  service. 

ISVC 

ISVC  does  not  have  its  own  web  service  interface.  It  relies  on  the  IPSWeb  interface  to 
expose  a  WSDL. 

Proposed  IWPC  Architecture 

Technologies 

•  ws-* 

The  WS-I  Basic  Profile  defines  a  basic  starting  point  for  web  service  interoperability  and 
most  S  OAP  frameworks  now  s  upport  t  he  b  asic  i  nteroperability  a  nd  s  ecurity  profiles. 
These  basic  s  tandards  ens  ure  t  hat  s  ervices  c  an  au  thenticate  and  exchange  S  OAP 
messages  w  ith  ot  her  WS-I  c ompliant  s ystems.  1 1  i  s  v  ital  th  at  any  N  et-Centric  sy  stem 
follow  t  hese  s  tandards.  J  2EE  1 . 4  i  ncorporates  t  hese  s  tandards  and  m  akes  i  t  m  uch 
easier  for  developers  to  expose  truly  interoperable  web  services. 

There  are  also  a  number  of  emerging  WS-*  standards  that  support  interoperable  ways 
of  m  aking  security  and  m  essage  delivery  guarantees.  T  hese  adv  anced  standards 
should  be  followed  w  herever  pos  sible;  t  hey  al  low  c  lients  an  d  s  ervices  t  o  m  ake 
assertions  about  the  messaging  system  state  that  could  not  be  done  with  the  basic 
SOAP/HTTP  protocol. 

•  Castor 

Castor  is  a  data  binding  framework  for  Java  objects.  It  has  never  been  popular  to  the 
point  of  achieving  standardization,  but  it  is  one  of  the  oldest  frameworks  for  marshaling 
Java  to  XML  or  Software  Query  Language  (SQL).  Castor  is  already  being  used  within 
the  IWPC  client  for  importing  and  exporting  plans  and  Courses  of  Action  (COAs)  to  XML 
documents  with  well-defined  schemas. 

•  Apache  Axis 

IWPC  currently  uses  Apache  Axis  1 .2.1  to  export  a  web  service  endpoint  to  the  IWPC 
service  applications.  Axis’s  default  configuration  is  not  suitable  for  interoperable,  WS-I 
compliant  w  eb  s  ervices.  H  owever,  i  t  does  hav  e  bui  It  i  n  s  upport  for  C  astor  as  a  n 
alternate  framework  for  marshaling  SOAP  messages. 

With  a  substantial  configuration  change  and  a  I  imited  amount  of  coding,  we  hope  to 
leverage  the  existing  Castor  mappings  from  the  IWPC  client  and  export  these  schemas 
as  the  base  data  types  for  an  i  nteroperable  web  service.  T  he  focus  of  this  pi  an  is 
repairing  and  updating  SDS  in  a  relatively  short  timeframe  to  achieve  SDS  integration 
with  other  web  service  consumers,  including  Global  Strike  Pilot  (GSP). 
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Tasks 

This  s  ection  I  ists  the  tasks  ne  eded  t  o  u  pdate  t  he  S  DS  w  eb  s  ervice  t  o  integrate  t  he 
existing  B  aseEBOData  C  astor  bi  ndings  f  rom  C  PT  w  ith  A  xis  and  c  reate  a  new 
deployment  for  Axis  1  .x  and  OC4J  10.1 .2. 

Again,  these  tasks  are  based  on  an  early  June  drop  of  the  I WPC  code  and  may  not 
totally  reflect  the  current  status  of  IWPC  4.2. 

a.  Provide  build  scripts  such  that  a  deployable  application  can  be  generated  in 
an  automated  way. 

Risk:  Low.  Probably  the  easiest  way  to  set  up  SDS  is  to  provide  an  Ant  script.  If  we 
encounter  dependency  cycles,  we  will  have  to  configure  the  master  build  to  do  a 
partial  pre-build. 

b.  Construct  l/l/SDL  that  defines  methods  for  at  least  the  following  functionality: 

•  Listing  available  plans 

•  Retrieving  available  plans 

•  Creating  new  plans 

Risk:  Low.  WSDL  development  is  a  generic  and  well  documented  process.  Already 
have  good  understanding  of  XML,  WSDL  and  XSD.  CPT  schema  for  BaseEBOData 
types  is  already  defined.  A  schema  for  a  limited  number  of  SDS-specific  classes  (i.e. 
Uniqueld  and  SdsUser)  will  need  to  be  c  reated.  N  eed  t  o  un  derstand  C  astor 
requirements  and  I  imitations  for  schema  definitions.  New  schemas  will  need  t  o  be 
tested  for  compatibility  with  Castor. 

c.  Configure  Axis  deployment  to  leverage  existing  Castor  bindings. 

Risk:  Medium.  Castor/Axis  integration  is  not  well  documented  and  Axis  deployment 
problems  can  be  difficult  to  debug.  Also,  IWPC  services  are  deployed  on  Axis  1.2.1. 
Apache  has  put  out  significant  bug  fixes  and  Axis  is  currently  at  version  1 .4.  Many  of 
these  fixes  focus  on  interoperability  issues  and  it  is  possible  that  some  of  them  will 
be  relevant  here.  We  may  need  to  consider  upgrading  Axis. 

d.  Integrate  new  deployment  into  some  kind  of  deployable  patch,  including: 

•  Review  pat  ch  d  esign  opt  ions  a  nd  c  oordinate  w  ith  i  ntegrators.  There  ar  e  a 
number  of  unanswered  questions  about  this  task.  Do  we  want  a  pre-install  or  a 
post-install  patch?  Can  we  patch  the  install  directory  and  redeploy  the  application 
to  the  app  server?  D  o  w  e  nee  d  t  o  pr  ovide  updates  t  o  t  he  I  nstallAnywhere 
installer? 

•  Implement  and  bundle  patch. 

•  Test  patch  bundle  installer. 
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Risk:  Unknown.  Depends  o  n  t  he  i  mplementation  c  hosen.  The  best  option  fora 
post-install  patch  is  to  provide  a  new  SDS  WAR  to  drop  into  the  install  directory  and 
redeploy.  This  will  not  work  if  we  need  to  make  actual  functional  changes  to  SDS. 
The  S  DS  E  JB  i  s  dep  loyed  as  par  t  of  I  PS  E  AR.  We  may  t  hen  need  t  o  pr  ovide 
functionality  to  update  the  EAR  directly. 

e.  Testing  and  documentation,  including: 

•  Unit  tests,  Functional  tests. 

•  Compatibility  tests.  (WS-I,  .NET,  etc.) 

•  Updates  to  SDS/IPS  VDDs. 

•  Document  web  service  external  interface. 

•  Support  for  security  accreditation. 

Risk:  Medium.  SDS  provides  very  few  unit  tests,  and  testing  will  be  difficult.  SDS 
must  b  e  de  ployed  t  o  a  c  ontainer  an  d  hav  e  a  r  eal  pi  an  av  ailable  i  n  t  he  dat  abase 
before  it  can  operate.  Tests  and  drivers  will  need  to  be  developed  for  such  functional 
tests. 

f.  Spiral  in  additional  functionality,  to  include  modifying  any  existing  plans. 

Risk:  Medium.  Adding  functionality  to  I  ock  and  update  s  hould  mostly  c  onsist  of 
updating  the  WSDL.  However,  i  n  order  to  m  ake  things  safe  for  concurrent  users, 
need  t  o  ens  ure  t  hat  o  bject  m  odification  t  ime  i  s  eas  ily  av  ailable  s  o  G  SP  c  an  I  ock, 
refresh,  edit,  unlock. 

Issues 

This  section  lists  operational  issues  which  would  need  to  be  addressed  before  pursuing 
any  further  efforts: 

a.  Axis  Documentation 

Detailed  documentation  on  Axis  serializers/deserializers  is  limited.  In  theory,  changing 
Axis  over  to  use  the  Castor  serializer  should  be  e  asy.  I  n  practice,  problems  with  the 
deployment  descriptor  are  difficult  to  debug.  Fortunately,  Axis  is  an  open  source  product 
and  we  can  refer  to  the  original  sources. 

b.  IWPC  Build  Management 

General  Dynamics  has  never  provided  an  automated  master  build  for  IWPC.  SRAhas 
done  s  ome  i  nternal  w  ork  on  i  ntegrating  t  he  bui  Ids,  and  t  he  S  RA  m  aster  bui  Id  d  oes 
produce  an  IPC  services  EAR.  However,  the  SDS  build  is  set  up  to  be  driven  by  the 
Maven3  build  tool  and  so  it  was  never  integrated  into  the  master  build. 
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One  would  need  to  eitherget  Maven  set  up  and  running  or  provide  an  Ant  build  for 
SDS.  In  either  case,  one  will  have  to  work  within  the  constraints  of  a  build  that  has  been 
badly  cross-coupled. 

c.  IWPC  Installers 

Either  a  n  ew  i  nstaller  w  ould  ne  ed  t  o  b  e  pr  ovided,  or  on  e  w  ould  ne  ed  t  o  up  date  t  he 
original  IWPC  installer.  Some  of  this  depends  on  deployment  -  will  the  SDS  changes 
be  deployed  as  a  post-install  patch,  or  as  an  update  to  IWPC  4.2? 

Other  Explored  Technologies 

Adobe  Flex  Data  Services  2 

Flex  i  s  a  1  Rich  I  nternet  A pplication’  ( RIA)  framework  t  hat  us es  s  tandard  J  2EE  s  erver 
technologies  an  d  t  he  F  lash  br  owser  pi  ug-in.  1 1  i  ncludes  a  t  ransport  m  echanism  t  o 
facilitate  communication  between  web  browsers  and  the  server. 

Flex  has  the  ability  to  communicate  asynchronously  with  a  flash  object  embedded  in  a 
web  page.  It  also  has  the  ability  to  translate  it’s  communications  with  the  web  page  into 
messages  using  the  Java  Messaging  Service  (JMS).  JMS  is  a  stable  communications 
interface  w  ith  r  obust  i  mplementations  av  ailable  from  al  I  m  ajor  appl  ication  s  erver 
vendors.  Most  vendors  also  provide  a  C  interface  to  allow  other  languages  to  utilize  the 
benefits  o  f  t  heir  pu  blish-subscribe  framework.  T  his  al  lows  s  eamless  c  ommunication 
between  br  owser  bas  ed  a  pplications  a  nd  v  irtually  any  ot  her  pi  atform.  T  his 
communication  method  is  depicted  in  Figure  5,  “Architectural  Use  of  Flex”,  below. 

It  should  be  n  oted  that  these  capabilities  could  also  be  achieved  with  the  Java  plug-in 
using  a  regular  applet.  A  deeper  analysis  would  need  to  be  performed. 


Figure  5:  Architecture  Use  of  Flex 


Alternate  JMS  Implementations 

Using  the  native  calling  interface  to  any  particular  application  server  will  tie  a  non -Java 
client  to  that  application  server.  However,  alternate  J  MS  implementations  exist  which 
are  portable  across  many  server  platforms  and  provide  a  standard,  stable  interface  to  all 
clients.  E  xamples  o  f  such  i  mplementations  ar  e  A  ctiveMQ  (  www.activemq.org)  and 
MantaRay  (www.coridan.com)  (among  others). 
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Yahoo!  User  Interface  Library 

In  order  to  ease  the  transition  from  fat  client  based  solutions  to  thin  client,  web  based 
solutions,  Yahoo!  Inc.  created  a  set  of  JavaScript  widget  libraries  that  allow  a  web  app 
to  appear  more  like  a  desktop  app.  This  library  abstracts  away  the  difficulties  in  creating 
a  consistent  layout  across  browsers  and  platforms.  In  removing  these  obstacles,  the 
developer  c  an  c  oncentrate  o  n  s  olving  real  pr  oblems,  i  nstead  o  f  wrestling  with  t  he 
technology. 

More  information  can  be  found  at  http://developer.vahoo.com/yui 

Summary 

The  analysis  that  was  completed  by  SRA  has  shown  that  the  current  state  of  the  Teneo 
prototype  software  has  some  fundamental  problems.  While  the  Teneo  concept  was  well 
received  and  ha  d  m  any  excellent  features,  the  i  mplementation  was  i  ntended  to  be  a 
prototype. 

As  s  uch,  T  eneo  i  n  i  ts  pr  esent  form  i  s  uns  table  an  d  unus  able  i  n  a  r  eal-world 
environment. 

Teneo’s  appealing  features  including: 

•  a  map  view  that  can  be  customized  with  different  backgrounds 

•  nodes  can  be  displayed  on  the  map  view 

•  a  map  view  that  can  be  layered  (introducing  the  ability  to  ‘de-clutter’  a  display) 

•  the  ability  to  save  the  map  view  as  a  picture  file  (JPEG) 

•  a  Gantt  chart  timeline  showing  the  ATO  activity 

•  a  ‘playback’  feature,  that  allows  the  user  to  advance  through  the  timeline,  showing 
the  current  state  on  the  map  view 

•  Threat  Rings’  showing  the  range  of  weapons  on  the  map 

•  data  import  capability  from  USMTF  and  Links  and  Nodes  formatted  files 

•  a  sorting  and  grouping  capability  for  the  data  in  the  ATO  in  a  grid  format. 

The  app  eal  o  f  Teneo  i  s  ov  ershadowed  by  its  f  railty  and  t  he  I  evel  of  di  fficulty  i  n 
maintaining  t  he  c  ode.  M  oving  f  orward  w  ith  t  he  c  urrent  s  ource  c  ode  b  ase  i  s  not 
recommended.  Recommendations  on  how  to  proceed  include  performing  a  functional 
comparison  between  Teneo  and  existing  lab  technology  in  order  to  reduce  duplicated 
functionality.  A  demonstrable  short  term  prototype  could  be  constructed  using  Java  and 
OpenMap  technologies.  In  lieu  of  a  short  term  prototype,  the  Teneo  feature  set  could 
be  a  focus  for  future  technology  prototyping. 
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Acronyms  and  Abbreviations 


AOC 

Air  Operations  Center 

AOC  SPVT 

AOC  Strategy  Planning  Visualization  Toolkit 

ATO 

Air  Tasking  Order 

BBN 

BBN  Technologies 

BCS 

Briefing  Composer  Service 

C4ISR 

Command,  Control,  Communications,  Computers, 
Intelligence,  Surveillance  and  Reconnaissance 

COA 

Course  of  Action 

CPT 

Collaboration  Planning  Tool 

DCOAD 

Dynamic  Course  of  Action  Development 

EAR 

Enterprise  Archive  File 

EJB 

Enterprise  Java  Bean 

ESRI 

Environmental  Systems  Research  Institute 

EW 

Electronic  Warfare 

GSP 

Global  Strike  Pilot 

IMOM 

Improved  Many  to  Many 

10 

Information  Operations 

IOPC-J 

10  Planning  Capability  -  Joint 

IOPC-X 

Integrated  Operations  Planning  Capability  -  Prototype 

IPC 

Inter-Process  Communications 

IPS 

Integrated  Planning  Service 

ISVC 

Intelligence  Service  (web  service) 

IWPC 

Information  Warfare  Planning  Capability 

J2EE 

Java  2  Enterprise  Edition  (Sun  Microsystems,  Inc.) 

JPEG 

Joint  Photographic  Experts  Group 

MDAL 

MIDB  Data  Access  Layer 

MIDB 

Modernized  Integrated  Data  Base 

.NET 

XML  Web  Services  Platform  (Microsoft  Corp.) 

PPS 

Plan  Publication  Services 

Pub-Sub 

Publish-Subscribe  Service 

RFS/RFA 

Request  for  Analysis  Service 

RIA 

Rich  Internet  Application 

RMI 

Java  Remote  Method  Invocation 

SDS 

Strategy  Development  Service 

SOAP 

Simple  Object  Access  Protocol 

SRA 

SRA  International,  Inc. 

TBONE 

Theatre  Battle  Operations  Net-Centric  Environment 

USMTF 

United  States  Message  Text  Format 

VDD 

Version  Description  Document 

WS 

Web  Service(s) 

WSDL 

WS  Description  Language,  WS  Definition  Language 

XML 

Extensible  Markup  Language 

XSD 

XML  Schema  Definition 
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Scope 

Identification 

This  document  applies  to  the  Teneo  software.  Teneo  is  a  prototype  and  does  not  have 
a  v  alid  version  num  ber.  R  eferences  t  o  t  he  I  nformation  Warfare  P  lanning  C  apability 
(IWPC)  apply  to  version  4.2,  delivered  on  June  21 ,  2006. 

System  Overview 

Discussions  w  ith  t  he  Electronic  Systems  C  enter  (  ESC)  I  ntelligence  S  urveillance  and 
Reconnaissance  Systems  Group  (ISRSG)  indicated  a  potential  for  migrating  code  from 
the  in-house  “Teneo”  prototyping  project  conducted  by  MITRE  Corporation  to  support 
the  maturing  Information  Operations  (10)  Planning  Capabilities  program.  The  purpose 
of  t  his  c  ode  migration  w  ould  be  t  o  I  everage  w  ork  al  ready  per  formed  i  n  t  he  ar  ea  of 
visualizations  of  air  operations  in  support  of  strategic  planning  to  further  the  10  Planning 
Capabilities  program. 

The  system  is  comprised  of  the  IWPC  server  software  running  on  the  Oracle  application 
server  (OAS),  the  IWPC  client  software,  and  the  Teneo  software.  Communication  from 
Teneo  to  the  IWPC  server  was  accomplished  using  standard  web  services.  The  Teneo 
software  r  equests  pi  ans  and  t  argets  from  I  WPC,  w  hich  i  1 1  hen  di  splays  on  i  ts  o  wn 
screen.  It  acts  like  a  viewer  for  the  data  inside  IWPC  without  actually  being  built  into  the 
original  system. 

This  was  a  pr  ototyping  effort,  so  there  are  no  c  urrent  or  planned  operating  sites  or 
support  agencies.  There  is  also  no  planned  maintenance. 

Document  Overview 

The  pur  pose  o  f  t  his  doc  ument  i  s  t  o  s  erve  as  a  c  ompanion  t  o  the  c  ontents  o  f  t  he 
delivered  software  disc.  1 1  will  show  what  the  software  is  supposed  to  accomplish,  its 
environmental  requirements  are,  and  how  to  work  with  the  disc’s  contents. 

This  document  is  unclassified  and  does  not  have  any  security  or  privacy  considerations. 

Referenced  Documents 

None. 
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Requirements 
Executable  Software 

The  disc  that  was  delivered  contains  the  following  files  that  are  necessary  for  execution: 
/software 

/client 

/Teneo 

AGCSN20.dll 

ESRI.MapObjects2.Control.dll 

ESRLMapObjects2.Core.dll 

ESRI.MapObjects2.Custom.dll 

InputTrace.webinfo 

Interop.MapObj  ects2.dll 

Lic.rtf 

OutputT  race.webinfo 

SandBar.dll 

T  eneo.application 

Teneo.exe 

Teneo.exe.config 

T  eneo.exe.manifest 

TeneoPubSub.dll 

TeneoService.dll 

iwpc-region-stub-l.O.dll 

log4net.dll 

log4net.xml 

preferences.xml 

teneo-data-l.O.dll 

teneo-tbone-net-stub-l.O.dll 

teneo-tbone-net.dll 

wse3policyCache.config 

/Scenario 

/Califon_UNC/ 

7_ll_2006_2_29_20_PM.jpg 

CDScheduIeObjects.xml 

RJammerScheduleObjects.xml 

SandstormScheduleObjects.xml 

TACMSPScheduleObjects.xml 

ag.xml 

deadnodes.xml 

eventList.xml 

scenario.xml 

taskScheduleObjects.xml 

thermoBaricScheduleObjects.xml 

/T  eneoTargetData 
/ATOs 
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/Maps 

GNC_N34_33_W125_38_F 

GNC_N34_33_W125_38_F 

ONCBase.tfw 

ONC_Base.tif 

/ShapeFiles 

CMTUtil.dll 

CoreUtil.dll 

Cxlmage.dll 

LinksCOAX.dbf 

LinksCOAX.shp 

LinksCOAX.shx 

LinksFIBER.dbf 

LinksFIBER.shp 

LinksFIBER.shx 

LinksLOS.dbf 

LinksLOS.shp 

LinksLOS.shx 

NodesCOAX.dbf 

NodesCOAX.shp 

NodesCOAX.shx 

NodesFIBER.dbf 

NodesFIBER.shp 

NodesFIBER.shx 

NodesLOS.dbf 

NodesLOS.shp 

NodesLOS.shx 

NodesRadar.dbf 

NodesRadar.shp 

NodesRadar.shx 

XMLArchive.dll 

califon.fcn 

califon.ln 

califon.xml 

expat_wrapper.dll 

gdall2.dll 

libexpat.dll 

proj.dll 

run.bat 

/rpf 

/IWPC 

/  app 

/mainmenu 

/bin 

mainmenu.jar 

mmthreads.jar 
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/bin 


images,  jar 


/server 


/properties 

mainmenu.properties 


iwpc-region-app-l.O.ear 
iwpc-sdsx-app-l.O.ear 
iwpc-xfmproxy-app- 1 .0.ear 
teneo  service.war 


Additional  files  are  necessary  in  order  to  get  the  IWPC  client  running  properly.  The  files 
included  on  the  disc  are  only  the  files  that  were  modified  for  this  project.  The  four  files 
for  IWPC  (mainmenu.jar,  mmthreads.jar,  images.jar,  and  mainmenu.properties)  should 
be  copied  over  an  existing  IWPC  client  installation  with  the  same  directory  structure  as 
the  disc. 


Source  Files 

The  source  files  are  located  in  the  disc  in  the  following  directory  structure  under  /source 
(files  modified  by  SRA  are  listed  in  bold  and  files  that  were  not  modified/added  by  SRA 
are  shown  in  ): 

/client 

/IWPC 

README.txt 

buildall.xml 

/ACE/common/com/btg/ace/util 

Encrypt.java 

/Database/iwpc/database/oracle/data 

PlanData.java 

/Main_Menu 

/mmthreads 

/applications: 

/teneo 

T  eneoThreadMain.j  ava 
/threadmanager 

ApplicationlDs.java 

ThreadManager.java 

/properties: 

mainmenu.properties 

/src 

/mainmenu 

MainMenuCOATabPanel.java 
MainMenuF  rame.j  ava 

/images 

Teneolcon.png 

/Teneo 

/T  eneoT  argetData 
/ATOs 
/Maps 

GNC  N34  33  W125  38  File.tfw 
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GNC_N34_33_W125_38_File.tif 

ONCBase.tfw 

ONC_Base.tif 

/ShapeFiles 

CMTUtiI.dll 

CoreUtil.dll 

Cxlmage.dll 

LinksCOAX.dbf 

LinksCOAX.shp 

LinksCOAX.shx 

Links_FIBER.dbf 

LinksFIBER.shp 

LinksFIBER.shx 

LinksLOS.dbf 

LinksLOS.shp 

LinksLOS.shx 

Nodes_COAX.dbf 

NodesCOAX.shp 

Nodes_COAX.shx 

Nodes_FIBER.dbf 

NodesFIBER.shp 

NodesFIBER.shx 

Nodes_LOS.dbf 

Nodes_LOS.shp 

Nodes_LOS.shx 

XMLArchive.dll 

califon.fcn 

califon.ln 

califon.xml 

expat_wrapper.dll 

gdall2.dll 

libexpat.dll 

proj.dll 

run. bat 

/rpf 

/TeneoUnclass: 

DISCLAIMER,  rtf 

DTimer.ocx 

ProductKeys.RTF 

Readme.rtf 

Teneo.csproj 

Teneo.csproj.user 

Teneo.ico 

Teneo.sln 

Teneo.suo 

Teneo_TemporaryKey.pfx 

UIDateTimeEditor.es 

UIDateTimeEditor.resx 

UILongString.es 

UILongString.resx 

app.config 

fATO.es 

fATO.resx 

fAbout.es 

fAbout.resx 

fDeploying.es 
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fDeploying.resx 

flmporter.es 

flmporter.resx 

fMain.es 

fMain.resx 

fPreferences.es 

fPreferences.resx 

fPropertyGrid.es 

fPropertyGrid.resx 

fResuftsNew.es 

fResuftsN  ew.resx 

fRow.es 

fRow.resx 

fScenario.es 

fScenario.resx 

fSpfash.es 

fSpfash.resx 

fTboneAto.Designer.es 

fTboneAto.es 

fTboneAto.resx 

fTboneAtoLogin.Designer.es 

fTboneAtoLogin.es 

fTboneAtoLogin.resx 

ficenses.iicx 

preferences.xmi 

spiash.jpg 

squareBiack.bmp 

squareBlue.bmp 

squareCyan.bmp 

squareDarkGreen.bmp 

squareGreen.bmp 

squareGrey.bmp 

squareMagenta.bmp 

squareNavy.bmp 

squareOrange.bmp 

squareOrange_actuai.bmp 

squarePurple.bmp 

squareRed.bmp 

squareWhite.bmp 

squareYeiiow.bmp 

vcrEnd.bmp 

vcrEndl.bmp 

vcrNext.bmp 

vcrPrev.bmp 

vcrReset.bmp 

vcrStart.bmp 

wse3poficyCache.config 

/BIOImporterDLL 

BIOImporterDLL.dll 
BIOImporterTest.exe 
/Class  Files 

AssemblyInfo.es 

CustomAxMap.es 

DevicePropertySort.es 

Devices.es 

LongStringEditor.es 
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RegionHandler.es 

WSMessageListener.es 

init.es 

/Properties 

Resources.Designer.es 

Resources.resx 

Settings.Designer.es 

Settings.settings 

/Scenario 

/CalifonJJNC 

CDScheduleObjeets.xml 
RJammerSeheduleObj  ects.xml 
SandstormScheduleObjects.xml 
TACMSPScheduleObjects.xml 
ag.xml 

deadnodes.xmi 

eventList.xml 

scenario. xml 

taskScheduleObjects.xml 

thermoBaricScheduleObjects.xml 

/Teneo 

Lie. rtf 

/support  software 

Microsoft.Web.Services3.dll 

SandBar.dll 

TeneoPubSub.dll 

TeneoService.dll 

Xceed.Editors.dll 

Xceed.Grid.UIStyle.dll.backup 

Xceed.Grid.dll 

Xceed.Grid.dll.backup 

Xceed.UI.dll 

iwpc-region-stub-l.O.dll 

iwpc-region-stub-l.O.pdb 

log4net.dll 

log4net.pdb 

log4net.xml 

teneo-data-l.O.dll 

teneo-data-l.O.pdb 

teneo-tbone-net-stub-l.O.dll 

teneo-tbone-net-stub-l.O.pdb 

teneo-tbone-net.dll 

teneo-tbone-net.pdb 

wse3policyCache.conflg 

/support  software: 

/TeneoPubSub 

TeneoPubSub.csproj 

TeneoPubSub.csproj.user 

TeneoPubSub.sln 

TeneoPubSub.suo 

TeneoSubscriber 

TeneoSubscriber.es 

/TeneoService 

TeneoService.csproj 

app.conflg 

/Properties 


C-ll 


/tbone 


Settings.Designer.es 
Settings.settings 
/Web  References 
teneo.ws 
/teneo.ws: 

Reference.es 
Reference. map 
TeneoService.wsdl 

/TeneoSubscriber 

TeneoHttpListener.es 

TeneoMessageListener.es 

TeneoSubscriber.es 

/Tester 

Main.cs 

TeneoMessageListenerTest.es 

TeneoService.dll 

Tester.csproj 

/Properties 

AssemblyInfo.es 


build.xml 

/teneo-data 

build.xml 
project.properties 
teneo-data.csproj 
teneo-data. sin 
teneo-data. suo 
/Properties 

AssemblyInfo.es 

/src/cs/mil/af/teneo/ 

/adapters 

AdapterSoureeExeeption.es 

DataSource.es 

/tbone 

AxisTBONEAdapter.es 

TBONEAdapter.es 

/data 


ATO.cs 

AbstractATO.es 

IWPCObject.es 

TBONEObject.es 

TeneoObject.es 

/tbone 


/teneo-tbone-axis 


TBONEATO.es 


BUILD.txt 

CONTENTS.txt 

axis-tbone-adapter.nunit 

build.xml 

classpath.xml 

jtools.jardesc 

local.properties 

project.properties 

teneo-tbone-axis.csproj 

teneo-tbone-axis.csproj.user 

teneo-tbone-axis.sln 
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teneo-tbone-axis.suo 

/Properties 

AssemblyInfo.es 

/TestCaseDriver: 

Program.es 

TestCaseDriver.csproj 

TestCaseDriver.csproj.user 

/Properties 

AssemblyInfo.es 

/lib 

System.Xml.jar 

System.jar 

TboneGatewayXmlBeans-20060630.jar 

XmlSchema-1.0.2.jar 

activation-1. 0.2.jar 

axiom-api-l.O.jar 

axiom-impl-l.O.jar 

axis2-kernel-1.0.jar 

backport-util-concurrent-2.2.jar 

bcprov-jdkl3-132.jar 

commons-beanutils-core-1.7.0.jar 

commons-codec-1. 3.jar 

commons-httpclient-3.0.jar 

commons-logging-1. 0.4.jar 

gatewayXmlBeans-20060630.jar 

javamail-1.3.2.jar 

j  axen-l.l-beta-7.jar 

log4j-1.2.11.jar 

mscorlib.jar 

neethi-l.O.l.jar 

stax-1. 1.2-dev.jar 

stax-api-l.O.jar 

teneo-data-l.O.jar 

tools 

wsdl4j-1.5.2.jar 

wss4j-1.5.0.jar 

xbean-2.1.0.jar 

xmlsec-1.3.0.jar 

/tools 

asm-2.2. l.jar 
axis-ant.jar 
checks  tyle 

checkstyle-all-4. 1  .jar 

cobertura.jar 

commons-cli-1 .0.j  ar 

commons-lang-2. l.jar 

easymock-2.2.jar 

jakarta-oro-2.0.8.jar 

jakarta-regexp-1.3.jar 

jaxen-l.l-beta-7.jar 

jdepend 

jdepend-2.9.jar 

lint4j.jar 

log4j-config.jar 

pmd 

pmd-3.7.jar 
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pmd-config.jar 
svnClient  Adapter,  j  ar 
svnant.jar 
svnjavahl.jar 

/checkstyle 

checkstyle-frames.xsl 

checkstyle-importcontrol.xml 

checkstyle-sun.xml 

checkstyle-suppressions.xml 

checkstyle-text.xsi 

/j  depend 

jdepend-frames.xsl 

/pmd 

arrow_down.gif 

arrow_up.gif 

corley-pmd-report.xslt 

fcoltable.css 

fcoltable.js 

only-priol.xslt 

only-prio2.xslt 

only-prio3.xslt 

only-prio4.xslt 

only-prio5.xslt 

pmd-report-per-class.xslt 

pmd-report.xslt 

sorttable.js 

wz-pmd-report.xslt 

/src 

/cs/mil/af/teneo/adapters/tbone 

CAxisTBONEAdapterImpl.es 

/ctest/mil/af/teneo/adapters/tbone 

TestCAxisTBONEAdapterImpl.es 

/dot 

project-deps.dot 

/java 

log4j.xml 

tbone-types.properties 

/mil/af 

/spvt/tbone 

/converters: 

ConversionException.java 
Converter,  java 
LocalObject.java 
package.html 

/dal 

AdapterSourceException.j  ava 
ConfigurationException.j  ava 
DataMaintenanceDAL.j  ava 
DataMaintenanceDALImpl.j  ava 
DataMaintenanceStub.java 
DownloadlnterruptedException.java 
IdT  ranslator.j  ava 
LocalObjectCache.java 
LocalObj  ectCachelmpl.j  ava 
LocalObj  ectN  otF  oundException.j  ava 
MappedRelationshipProxy.j  ava 
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RelationshipProxy.j  ava 

TASObj  ectCache.j  ava 

TASObj  ectNotFoundException.j  ava 

TBONEConnectionConstants.java 

TBONEQuery.java 

XMLBeansDataMaintenanceStub.java 

package.html 

/state 

DALState.java 

DataMaintenanceDALImplState.java 
LocalObjectCacheState.java 
MappedRelationshipProxyState.java 
StatefulC  ache.j  ava 
TASObjectCacheState.java 
package.html 
/gnuclasspath 

PromiscuousCertiflcateHandler.java 

package.html 

/loaders 

AbstractLoader.j  ava 
Default  ATOLoader.j  ava 
Loader. java 
package.html 

/types 

ATOType.java 
TasType.java 
L  nknownType.j  ava 
package.html 

/utils 

ArrayUtils.java 
EqualsBuilder.j  ava 
HashCodeBuilder.j  ava 
PropertyUtils.j  ava 
PropertyUtilsBean.j  ava 
StringUtils.java 
XMLSafePropertyBean.java 
package.html 
/teneo/ adapters/tbone : 

JAxisTBONEAdapterlmpl.java 

JExceptionHelper.java 

package.html 

/converters 

ATOConverter.j  ava 
AbstractConverter.j  ava 
LocalObjectWrapper.java 
package.html 

/loaders 

ATOLoader.j  ava 
package.html 

/test/mil/af: 

BaseTest.java 

/spvt/tbone: 

/dal: 

TestAdapterSourceException.java 
TestDataMaintenanceDAL.j  ava 
TestDataMaintenanceStub.j  ava 
TestldT  ranslator.j  ava 
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TestLocalObjectCache.java 

TestRelationshipProxy.java 

TestTASObjectCache.java 

TestTBONEQuery.java 

/loaders 

TestAbstractLoader.java 

TestDefaultATOLoader.java 

/types 

TestATOType.java 
TestTasType.java 
TestUnknownType.j  ava 

/utils 

TestPropertyUtils.java 

TestXMLSafePropertyBean.java 

/tools/org/apache/log4j 

AppenderSkeletonBeanlnfo.java 
ConsoleAppenderBeanlnfo.j  ava 
LayoutBeanlnfo.j  ava 
PatternLayoutBeanlnfo.j  ava 
WriterAppenderBeanlnfo.java 

/tools 

CONTENTS.txt 
ikvmc.exe.config 
ikvmstub.exe. config 

/teneo-tbone-net 

app. config 

build.xml 

classpath.xml 

local.properties 

project.properties 

tbone-types.Designer.cs 

tbone-types.resx 

teneo-tbone-net.csproj 

teneo-tbone-net.csproj.user 

teneo-tbone-net.nunit 

teneo-tbone-net.sln 

teneo-tbone-net.suo 

wse3policyCache.config 

/Properties: 

AssemblyInfo.es 

Settings.Designer.es 

Settings.settings 

/TestCaseDriver 

Program.es 
T  estCaseDriver.csproj 
/Properties 

AssemblyInfo.es 

/lib 

Microsoft.Web.Services3.dll 

log4net.dll 

log4net.pdb 

log4net.xml 

teneo-data-l.O.dii 

teneo-data-l.O.pdb 

/tools 

NMock2.dll 
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/src 


nunit.common.dll 

nunit.core.dll 

nunit.framework.dlI 

/cs/mil/af 

/spvt/tbone 

/converters: 

ConversionException.es 

Converter.es 

LocalObject.cs 

/dal 

AdapterSourceException.es 

ConfigurationException.es 

DataMaintenanceDAL.es 

DataMaintenanceDALImpl.es 

DataMaintenanceStub.es 

DownloadInterruptedException.es 

IdTranslator.es 

LocalObjectCache.es 

LocalObjectCacheImpl.es 

LocalObjectNotFoundException.es 

MappedRelationshipProxy.es 

RelationshipProxy.es 

Security.es 

TASObjectCache.es 

TASObjectNotFoundException.es 

TBONEConnectionConstants.es 

TBONEQuery.es 

WSE3DataMaintenanceStub.cs 

/state 

DALState.es 

DataMaintenanceDALImplState.es 

LocalObjectCacheState.es 

MappedRelationshipProxyState.es 

StatefulCache.es 

TASObjectCacheState.es 

/loaders 

AbstractLoader.es 

DefaultATOLoader.es 

Loader.es 

/types 

ATOType.es 

TasType.es 

UnknownType.es 

/utils 

EqualsBuilder.es 

HashCodeBuilder.es 

Log4NetLogger.cs 

LogFactory.es 

Logger.es 

NullLogger.es 

PropertyUtils.es 

PropertyUtilsBean.es 

StringUtils.es 

/teneo/adapters/tbone 

WSE3TBONEAdapter.cs 
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./server 


/converters 

ATOConverter.es 

AbstractConverter.es 

LocalObjectWrapper.es 

/loaders 


/ctest/mil/af/ 

BaseTest.es 

/spvt/tbone 

/dal: 


ATOLoader.es 


TestDataMaintenanceDAL.es 

TestIdTranslator.es 

TestLocalObjectCache.es 

TestRelationshipProxy.es 

TestTASObjectCache.es 

TestTBONEQuery.es 

/loaders 


TestAbstractLoader.es 

TestDefaultATOLoader.es 

/types 

TestATOType.es 

TestTasType.es 

TestLnknownType.es 

/wsdl 


/xsd 


DataMaintenanceService.wsdl 


GatewayServices.xsd 

TBONE.xsd 


/Region 

Region.jpx 

Region.jpx.local 

Region.jpx.local- 

build.xml 

classpath.xml 

lib.library 

local.properties 

project.properties 

stubs.library 

/client/mil/af/iwpc/region/client 

ClientTest.java 

/lib 

MDALobj  ects.j  ar 

UtilsCoreData.jar 

UtilsStorageAdapters.j  ar 

activation-1 .0.2.  j  ar 

axis-1. 4.  jar 

castor-1. 0.1-xml.jar 

commons-discovery-0.2.jar 

commons-logging.jar 

iwpcdb2.jar 

javamail-1.3.2.jar 

jaxrpc-l.l.jar 

jaxrpc.jar 

jug-jar 

log4j-1.2.11.jar 
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saaj-1.2.jar 
tools 
utils,  jar 

wsdl4j-1.5.1.jar 
xerceslmpl-2.8.0.jar 
xml-apis.jar 
zonule-utils-1 .0.j  ar 

/tools 

asm-2.2.1.jar 

axis-ant.  jar 

checkstyle-all-4.1  .j  ar 

cobertura.jar 

commons-cli-l.O.jar 

commons-lang-2.1.jar 

jakarta-oro-2.0.8.jar 

j  akarta-regexp-1 .3.j  ar 

jaxen-l.l-beta-7.jar 

jdepend-2.9.jar 

lint4j.jar 

log4j-config.jar 

pmd-3.7.jar 

pmd-conlig.jar 

svnClientAdapter.j  ar 

svnant.jar 

svnjavahl.jar 

/checkstyle 

checkstyle-frames.xsl 

checkstyle-importcontrol.xml 

checkstyle-sun.xml 

checkstyle-suppressions.xml 

checkstyle-text.xsl 

/jdepend 

j  depend-frames.xsl 

/pmd 

arrow_down.gif 

arrow_up.gif 

corley-pmd-report.xslt 

fcoltable.css 

fcoltable.js 

only-priol.xslt 

only-prio2.xslt 

only-prio3.xslt 

only-prio4.xslt 

only-prio5.xslt 

pmd-report-per-class.xslt 

pmd-report.xslt 

sorttable.js 

wz-pmd-report.xslt 

/java: 

log4j.xml 

/mil/af/iwpc/ 

/region/service 

RegionExtensionWrapper.java 

/axis/wrappers 

GetTargetRequest.java 
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Target.java 

TargetResults.java 

TargetsList.java 

/sds/axis 

CastorDeserializer.j  ava 
CastorDeserializerFactory.java 
CastorSerializer.java 
CastorSerializerFactory.java 
MappingSingleton.j  ava 

/latex 

GNCI-ROM-Assessment.tex 

GSP-IOPCX-plan.tex 

GSP-IWPC-plan.tex 

IPS-interface.tex 

IS  V  C-interface.tex 

SDS-interface.tex 

iwpc.eps 

iwpc.orig.png 

iwpc.png 

technology-assessment.tex 

/map 

RegionTypeMapping.xml 

/stub-test/mil/af/iwpc/sdsx/client 

LiveServiceTest.java 

TestGetEffect.java 

TestGetPlan.java 

TestGetTarget.java 

/test/mil/af/iwpc 

AllTests.java 

/region/castor 

AllTests.java 

BindingTest.java 

TestGetTargetRequestBinding.java 

TestGetTargetResponseBinding.java 

/sds/castor 

AllTests.java 
BindingTest.j  ava 
TestLockBinding.java 
TestLockRequestBinding.j  ava 
TestStratPlanBinding.j  ava 

/wsdd 

server-config.wsdd 

/wsdl 

Region.wsdl 

/xsd 

Region-Types.xsd 

/SDSX 

build. xml 
classpath.xml 
local.properties 
proj  ect.properties 
/lib 

SdsCommon.jar 

SdsWebService.jar 

UtilsCoreData.jar 

UtilsStorageAdapters.jar 
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activation-1. 0.2.jar 
axis-1. 4.jar 
castor-1. 0.1-xml.jar 
commons-discovery-0. 2.jar 
commons-logging.jar 
javamail-1.3.2.jar 
jaxrpc-l.l.jar 
jaxrpc.jar 

jug-jar 

log4j-1.2.11.jar 
saaj-1.2.jar 
utils,  jar 
wsdl4j-1.5.1.jar 
xerceslmpl-2.8.0.jar 
xml-apis.jar 
zonule-utils-1 .0.j  ar 
/tools 

asm-2.2.1.jar 
axis-ant.  jar 
checkstyle 

checkstyle-all-4.1  .j  ar 

cobertura.jar 

commons-cli-l.O.jar 

commons-lang-2.1.jar 

jakarta-oro-2.0.8.jar 

j  akarta-regexp-1 .3.j  ar 

jaxen-l.l-beta-7.jar 

jdepend 

jdepend-2.9.jar 

lint4j.jar 

log4j-config.jar 

pmd 

pmd-3.7.jar 

pmd-config.jar 

svnClientAdapter.j  ar 

svnant.jar 

svnjavahl.jar 

/checkstyle 

checkstyle-frames.xsl 

checkstyle-importcontrol.xml 

checkstyle-sun.xml 

checkstyle-suppressions.xml 

checkstyle-text.xsl 

/jdepend 

j  depend-frames.xsl 

/pmd 

arrow_down.gif 

arrow_up.gif 

corley-pmd-report.xslt 

fcoltable.css 

fcoltable.js 

only-priol.xslt 

only-prio2.xslt 

only-prio3.xslt 

only-prio4.xslt 

only-prio5.xslt 
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/src 


pmd-report-per-class.xslt 

pmd-report.xslt 

sorttable.js 

wz-pmd-report.xslt 


/java 


/latex 


log4j.xml 

/mil/af/iwpc 

/client/axis/utils 

ClientConfigUtils.j  ava 
/data/ebodata 

StratPlanWrapper.java 

/castor/handlers 

CPTBooleanHandler.java 
CPTDateHandler.j  ava 
CPTDayHandler.j  ava 

/sdsx 

/service 

SDSExtensionWrapper.java 

TargetType.java 

/axis: 

/encoding 

CastorDeserializer.j  ava 
CastorDeserializerFactory.java 
CastorSerializer.j  ava 
CastorSerializerFactory.j  ava 
MappingSingleton.j  ava 
/wrappers 

GetBaseEBODataRequest.java 
GetBaseEBODataResponse.java 
GetEffectRequest.j  ava 
GetEffectResponse.j  ava 
GetPlanRequest.j  ava 
GetPlanResponse.j  ava 
GetTargetRequest.java 
GetTargetResponse.java 


GNCI-ROM-Assessment.tex 

GSP-IOPCX-plan.tex 

GSP-IWPC-plan.tex 

IPS-interface.tex 

IS  V  C-interface.tex 

SDS-interface.tex 

iwpc.eps 

iwpc.orig.png 

iwpc.png 

technology-assessment.tex 

/map 

CoaMapping.xml 
SDSEBOTypeMapping.xml 
SDSTypeMapping.xml 
SDSXTypeMapping.xml 
StratPlanMapping.xml 
/stub-test/mil/af/iwpc/sdsx/client 
LiveServiceTest.j  ava 
T  estGetEffect.j  ava 
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TestGetPlan.java 

TestGetTarget.java 

/test/mil/af/iwpc 

AllTests.java 

/cpt/castor 

AllTests.java 
BindingTest.java 
TestCapabilityBinding.java 
TestCausalLinkBinding.java 
TestEffectBinding.java 
TestFacilityTargetBinding.j  ava 
TestGenericAssetBinding.java 
TestGenericTargetBinding.j  ava 
TestlndicatorBinding.java 
TestObsOppBinding.java 
TestPhaseBinding.java 
TestPlanElementBinding.java 
TestStratPlanBinding.java 
TestUnitTargetBinding.java 
/sds/castor 

AllTests.java 
BindingTest.java 
TestLockBinding.java 
TestLockRequestBinding.java 
TestSdsUserBinding.j  ava 
TestStratPlanBinding.java 
TestUniqueldBinding.java 
/sdsx/castor 

AllTests.java 

BindingTest.java 

TestGetEffectRequestBinding.java 

TestGetEffectResponseBinding.java 

TestGetPlanRequestBinding.java 

TestGetPlanResponseBinding.java 

TestGetTargetRequestBinding.java 

TestGetTargetResponseBinding.java 

/wsdd 

sdsx-client-config.wsdd 

server-config.wsdd 

/wsdl 

SDSX.wsdl 

/xsd 

SDS-Types.xsd 

SDSX-Types.xsd 

V42_AssetElement.xsd 

V  42_Asset_List.xsd 

V42_Asset_List_Structure.xsd 

V42_BaseEBOData.xsd 

V42_CapabilityCollection.xsd 

V42_EffectElement.xsd 

V42_IO_Plan.xsd 

V42_IO_Plan_Basic.xsd 

V42_IO_Plan_Intermediate.xsd 

V42_IO_Plan_Structure.xsd 

V42_IO_Plan_TargetAndAsset.xsd 

V42  IndicatorCollection.xsd 
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V42_IndicatorStatus.xsd 

V42_JTTTargetList.xsd 

V42_LinkElement.xsd 

V42_ObsOpsCollection.xsd 

V42_PlanElement.xsd 

V42_Plan_Basic.xsd 

V42_Plan_CC.xsd 

V42_StratPlan.xsd 

V42_TargetElement.xsd 

V  42_Tar  getList.xsd 

V42_Target_List_Structure.xsd 

/XFMProxy 

build. xml 
classpath.xml 
local.properties 
proj  ect.properties 

/lib: 

activation-1. 0.2.jar 

axis-1. 4.jar 

castor-1. 0.1-xml.jar 

commons-discovery-0. 2.jar 

commons-logging.jar 

javamail-1.3.2.jar 

jaxrpc-l.l.jar 

jaxrpc.jar 

jug-jar 

log4j-1.2.11.jar 

saaj-1.2.jar 

wsdl4j-1.5.1.jar 

wss4j-1.5.0.jar 

xerceslmpl-2.8.0.jar 

xml-apis.jar 

/src 

/java 

log4j.xml 

/mil/af/iwpc/xfmproxy 

Constants,  java 

/service 

XFMProxy  .java 

/axis 

AxisF  aultHandler.j  ava 
P  WCallback.j  ava 
/transforms 

SoapFilter.java 

WSAddressingVersionFix.j  ava 

/wsdd 

server-config.wsdd 

/wsdl 

DataMaintenanceService.wsdl 

/xsd 

GatewayServices.xsd 

TBONE.xsd 

/teneo_service 

build.xml 

/lib: 

/axis: 
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axis-ant.  jar 
axis-schema,  jar 
axis.jar 

commons-discovery-0. 2.jar 

commons-logging-1. 0.4.jar 

jaxrpc.jar 

log4j-1.2.8.jar 

log4j  .properties 

saaj.jar 

wsdl4j-1.5.1.jar 

/xml 

xerceslmpl.jar 

xml-apis.jar 

/src/mil/af/teneo 

TeneoService.java 

/client 

TeneoMessageHandler.java 

TeneoSubscriber.java 

/exceptions 

MalformedEndpointException.j  ava 

/publisher 

AbstractPublisher.java 
T  cpPublisher.j  ava 

/test 

ServiceTest.java 

/support  files 

/axis  _template_ 

flngerprint.jsp 
happy  axis,  jsp 
il8nLib.jsp 
index.html 
index,  jsp 
/WEB-INF 

server-config.wsdd 

users.lst 

web.xml 

/classes 


il8n.properties 

il8n_ja.properties 

axis-ant.  jar 
axis-schema,  jar 
axis.jar 

commons-discovery-0. 2.jar 

commons-logging-1. 0.4.jar 

jaxrpc.jar 

log4j-1.2.8.jar 

saaj.jar 

wsdl4j-1.5.1.jar 
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The  source  code  for  a  proof-of-concept  demo  is  also  included  on  the  disc  under  the  ‘ flex  demo ’ 
directory: 

/java  client 

build.bat 

README.txt 

run.bat 

/lib 

flex-bootstrap  .j  ar 
flex-messaging-common.jar 
flex-messaging-opt.  j  ar 
flex-messaging-req.jar 
flex-messaging,  j  ar 
javax77.jar 
j  ms. jar 
oc4j.jar 
oc4j  client,  jar 
servlet,  jar 
xerceslmpl.jar 
/src 

/demo 

Test,  java 

/web  client 

application.xml 

build.xml 

chat.css 

chat_placeholder.html 

index.html 

README.txt 

xindex.html 

/bridge 

FABridge.as 

FABridge.js 

/images 

blinddown.gif 

blindup.gif 

resize_gripper.gif 

version.swf 

/js 

xmlutility.js 
/scrip  taculous 

builder.js 

controls.js 

dragdrop.js 

effects.js 

jsutils.js 
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prototype.js 
scriptaculous.js 
slider,  js 
unittest.js 
/messageservice 
/dashboard 

Chat.mxml 

dashboard.mxml 

main.css 

README.html 

/META-INF 

/WEB-INF 

jrun-web.xml 

web.xml 

/classes/samples/dashboard 

JMSChat.class 

/flex 

data-management-config.xml 

flash-unicode-table.xml 

flex-config.xml 

flex-webtier-config.xml 

global.css 

jgroups-default.xml 

license.properties 

localFonts.ser 

macFonts.ser 

messaging-config.xml 

mxml-manifest.xml 

proxy-config.xml 

remoting-config.xml 

services-config.xml 

winFonts.ser 

/jars 

asc.jar 

batik-awt-util.j  ar 
batik-bridge,  jar 
batik-css.  jar 
batik-dom.jar 
batik-ext.jar 
batik-gvt.jar 
batik-parser,  jar 
batik-script,  jar 
batik-svg-dom.j  ar 
batik-svggen.jar 
batik- transcoder,  j  ar 
batik-util,  jar 
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batik-xml.  jar 

commons-collections.jar 

commons-discovery,  j  ar 

commons-logging.j  ar 

commons-logging.properties 

flex-messaging-common.jar 

flex-web  tier,  jar 

license,  jar 

mm-velocity- 1 .4.  j  ar 

mxmlc.jar 

oscache.jar 

swfkit.jar 

xerceslmpl.jar 

xercesPatch.jar 

xmlParser  APIs,  j  ar 

/libs 

charts.swc 

fds.swc 

flex.swc 

framework.swc 

playerglobal.swc 

rpc.swc 

utilities.swc 

/locale/en_US 

chartsrb.swc 

fdsrb.swc 

frameworkrb.swc 

/themes 

haloclassic.swc 

/lib 

backport-util-concurrent.jar 
cfdataservicesadapter.j  ar 
cfgatewayadapter.  j  ar 
commons-codec.jar 
commons-httpclient.jar 
commons-logging.j  ar 
concurrent.jar 
flex-bootstrap.jar 
flex-messaging-common.j  ar 
flex-messaging-opt.jar 
flex-messaging-req.jar 
flex-messaging,  j  ar 
/  src/ samples/ dashboard 
JMSChat.java 
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Packaging  Requirements 

No  special  packaging  or  marking  must  be  made  for  copies  of  the  Teneo  software. 

Qualification  Provisions 

To  validate  that  a  body  of  software  is  a  valid  copy  of  Teneo,  verify  that  each  executable 
file  referenced  in  section  3.1  under  the  /Teneo  directory  (not  including  the  encapsulated 
Scenario  directory)  has  an  identical  counterpart  in  the  software  in  question. 

A  valid  copy  of  the  source  will  contain  all  of  the  files  listed  in  section  3.2. 

Software  Support  Information 
“As  Built”  Software  Design 

Teneo,  as  it  was  received,  was  a  ‘  rapid  prototype’  style  software  package.  As  such, 
Teneo  was  never  scrutinized  via  formal  design  review,  and  no  formal  documentation  for 
Teneo  (e.  g  .,  detailed  design  document)  was  generated,  or  at  least  provided  by  the 
developer.  SRA  completed  an  evaluation  of  the  Teneo  software  and  the  architecture  of 
the  s  ystem  t  o  w  hich  i  t  w  as  t  o  be  i  ntegrated  t  hrough  pr  oof-of-concept  t  esting  and 
prototyping. 

The  Teneo  software  is  integrated  into  the  main  menu  of  IWPC  by  minor  modifications  to 
the  IWPC  source  code  that  includes  a  system  call  to  launch  the  Teneo  executable.  A 
custom  w  eb  s  ervice  i  s  us  ed  t  o  m  ore  eas  ily  i  ntegrate  t  he  .  NET  e  nvironment  w  ith  t  he 
J2EE  (Java  2  E  nterprise  Edition)  architecture.  T  his  web  service  utilizes  a  s  tandard 
‘callback’  approach  for  the  server  to  asynchronously  pass  messages  to  a  s  ubscribing 
client. 

Compilation/Build  Procedures 

To  build  Teneo,  the  following  tools  must  be  acquired: 

1.  Ant  1.6.5 

2.  Java  Development  Kit  1 .4.2 

3.  JDepend  2.9.1 

4.  Microsoft  C#  Compiler  (CSC) 

Before  beginning,  set  the  environment  variable  ‘JAVA_HOME’  to  point  to  the  installation 
directory  in  which  the  Java  Development  Kit  is  installed. 

1.  Underthe  source  directory,  in  the  client/IWPC  directory,  unzip  the  June  21,  2006, 
release  of  IWPC  4.2.  Do  not  replace  the  files  that  are  already  in  this  directory.  The 
files  t hat  ar e  already  t  here  are  our  m  odifications  t o  t  he  base  I WPC  s ource  c ode. 
Run  the  command  ‘ant  -f  build_all.xml’  to  produce  all  of  the  jar  files  in  IWPC.  The 
jar  f  iles  t  hat  ar  e  i  mportant  ar  e  t  he  ‘  images.jar’  I  ocated  i  n  t  he  bin  di  rectory  and 
‘mainmenu.jar’  and  ‘ mmthreads.jar’  located  in  the  Main_Menu/bin  directory.  These 
jars  can  replace  the  jars  of  the  same  name  in  an  IWPC  installation. 


C-29 


2.  The  Teneo  c  lient  c  an  be  c  ompiled  us  ing  Microsoft  Visual  S  tudio  by  openi  ng  t  he 
Teneo.sln  file  located  under  the  source  directory  in  the  client/Teneo/Teneo_Unclass 
folder.  T  eneo’s  publ  ish-subscribe  c  lient  I  ibraries  c  an  al  so  be  b  uilt  us  ing  M  icrosoft 
Visual  Studio  by  opening  the  TeneoPubSub.sIn  file  under  the  source  directory  in  the 
client/support  software/TeneoPubSub  folder. 

3.  Under  the  ‘source/client/support  software’ d  irectory,  r  un  ant  to  build  t  he  TBONE 
adapters  for  C#. 

4.  Under  the  ‘ source/server/Region ’  directory,  run  ant  to  build  the  region  service.  This 
will  create  iwpc-region-app-1 .0.ear  in  the  dist  directory  which  can  be  deployed  to  the 
application  server  using  the  enterprise  manager  (console). 

5.  Under  t  he  1  source/server/SDSX  di  rectory,  r  un  ‘  ant  dist  ear’  to  b  uild  t  he  S  DS 
extension  service.  This  will  create  iwpc-sdsx-app-1 .0.ear  in  the  dist  directory  which 
can  be  deployed  to  the  application  server  using  the  enterprise  manager  (console). 
Run  ant  cstub  to  create  the  C#  stub  classes  for  this  service. 

6.  Under  t  he  ‘  source/server/XFMProxy’  di  rectory,  run  ‘  ant  dist  ear’  to  bui  Id  t  he  X  FM 
Proxy  service.  This  will  create  iwpc-xfmproxy-app-1 .0.ear  in  the  dist  directory  which 
can  be  deployed  to  the  application  server  using  the  enterprise  manager  (console). 

7.  Under  t  he  ‘  source/server/teneo_service’  di  rectory,  r  un  1  ant  compile 
make_service_war’  to  build  the  Teneo  pu blish-subscribe  service.  This  will  create 
teneo_service.war  in  the  base  directory  which  can  be  deployed  to  the  application 
server  using  the  enterprise  manager  (console). 

The  p roof-of-concept  code  is  intended  to  be  used  more  as  a  reference  point  for  how 
browser-to-JMS  (Java  Messaging  System)  messaging  can  occur,  but  the  code  can  be 
compiled.  In  order  to  satisfy  all  of  the  dependencies,  it  must  be  compiled  on  a  machine 
that  has  Oracle  Containers  for  Java  (OC4J)  installed,  as  well  as  the  base  Adobe  Flex 
service  installed  on  that  OC4J  instance. 

To  compile  the  web  client,  run  ant  in  the  ‘flex  demo/web  client’  directory  after  modifying 
the  build. xml  to  point  the ‘oracle-home’  property  at  base  directory  of  the  Oracle/OC4J 
installation.  A  Iso,  make  s  ure  that  t  he  O  C4J  i  nstance  h  as  t  he  following  J  NDI  s  etup: 
jms/amq factory  and  jms/flex/TopicConnectionFactory  as  JMS  topic  connection  factories, 
and  jms/amqtopic  as  a  JMS  topic.  To  compile  the  Java  client  for  this  proof  of  concept, 
run  ant  in  the  flex  demo/java  client  directory. 

Modification  Procedures 

None. 

Computer  Hardware  Resource  Utilization 

Teneo  w  ill  r  un  on  a  standard  p  ersonal  c  omputer  u  nder  t  he  .NET  e  nvironment.  No 
special  considerations  need  to  be  made  in  order  to  utilize  this  software. 

Requirements  Traceability 

Not  applicable. 
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Notes 

Teneo  is  a  prototype  and  is  not  intended  for  production  use.  The  purpose  of  SRA’s  work  was  to 
evaluate  the  client  software  and  the  architecture  as  a  whole,  with  this  evaluation  resulting  in  the 
recommendation  to  completely  redesign  and  rewrite  Teneo. 

Acronyms  and  Abbreviations 

AOC  Air  Operations  Center 

AOC  SPVT  AOC  Strategy  Planning  Visualization  Toolkit 
C4ISR  Command,  Control,  Communications,  Computers,  Intelligence, 
Surveillance  and  Reconnaissance 
EAR  Enterprise  Archive  File 

EJB  Enterprise  Java  Bean 

ESRI  Environmental  Systems  Research  Institute 

IOPC-J  Information  Operations  Planning  Capability  -  Joint 
IOPC-X  Integrated  Operations  Planning  Capability  -  Prototype 
IPS  Integrated  Planning  Service 

ISVC  Intelligence  Service  (web  service) 

IWPC  Information  Warfare  Planning  Capability 

J2EE  Java  2  Enterprise  Edition  (Sun  Microsystems  Inc.) 

MDAL  MIDB  Data  Access  Layer 

MIDB  Modernized  Integrated  Data  Base 

.NET  Microsoft  XML  Web  Services  platform 

SDS  Strategy  Development  Service 

SOAP  Simple  Object  Access  Protocol 

SRA  SRA  International,  Inc. 

WS  Web  Service(s) 

WSDL  Web  Services  Description  Language,  Web  Services  Definition  Language 
XML  Extensible  Markup  Language 

XSD  XML  Schema  Definition 
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Summary 


The  Information  Operations  Planning  Capability  -  Experiment  (IOPC-X)  task  was  a  risk 
reduction  effort  to  help  refine  future  technical  and  operational  net-centric  requirements.  The 
primary  goals  of  IOPC-X  were  to: 

■  Design  and  develop  a  software  net-centric  infrastructure  prototype  enabling  rapid 
integration  of  new  capability  modules  (CM) 

■  Demonstrate  a  pluggable  infrastructure  of  core  Infonnation  Warfare  Planning 
Capability  (IWPC)  tools  and  Information  Operations  (10)  analysis  capabilities 

■  Align  with  the  Net-Enabled  Command  Capability  (NECC)  and  Net-Centric  Core 
Enterprise  Services  (NCES)  standards  and  capabilities 

IOPC-X  was  developed  under  the  Strategy  Planning  Visualization  Tool  (SVPT)  contract  for  the 
711  Human  Performance  Wing  Human  Effectiveness  Directorate  (RH).  Primary  Operational  and 
Technical  direction  for  this  task  was  provided  by  the  Joint  Forces  Command  (JFCOM) 
Engineering  Staff  Section  (J7)  Virtual  Integrated  Support  for  the  Infonnation  Operations 
Environment  (VisIOn)  Technical  Integrative  Product  Team. 
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Introduction 


The  Information  Operations  Planning  Capability  -  Experiment  (IOPC-X)  task  was  a  risk 
reduction  effort  to  help  refine  future  technical  and  operational  net-centric  requirements.  The 
primary  goals  of  IOPC-X  were  to: 

■  Design  and  develop  a  software  net-centric  infrastructure  prototype  enabling  rapid 
integration  of  new  capability  modules  (CM) 

■  Demonstrate  a  pluggable  infrastructure  of  core  Infonnation  Warfare  Planning 
Capability  (IWPC)  tools  and  Information  Operations  (10)  analysis  capabilities 

■  Align  with  the  Net-Enabled  Command  Capability  (NECC)  and  Net-Centric  Core 
Enterprise  Services  (NCES)  standards  and  capabilities 

The  standards  used  for  the  IOPC-X  architecture  were  Department  of  Defense  (DoD)  Infonnation 
Technology  Standards  Registry  (DISR)  registered  standards.  The  architecture  also  followed  the 
guidance  provided  in  the  Net-Centric  Operational  Warfare  Reference  Model  (NCOW-RM).  The 
Architecture  was  based  on  the  use  of  a  Web  Service  Oriented  Architecture  leveraging  a  J2EE 
middle  tier.  In  order  to  address  the  requirements  of  the  Net-Centric  Data  Strategy,  a  data  access 
service  leveraging  the  Jena  Ontology  Library  was  developed  to  allow  capabilities  to  register 
Ontologies  for  persistence  and  querying  of  their  data  model  elements  via  SPARQL  queries. 

This  experiment  also  tested  the  use  of  new  thin  client  technologies  such  as  Flex/Flash, 
ActionScript  and  JavaScript  as  well  as  the  potential  for  discovery  and  distribution  of  Eclipse 
Rich  Client  Platform  Open  Services  Gateway  Initiative  (OSGi)  compliant  fat  client  plug-in 
modules  by  leveraging  the  NCES  UDDI  registry.  Authentication  and  authorization  proof-of- 
concepts  were  perfonned  in  order  to  test  the  ability  of  the  infrastructure  to  leverage  the  NCES 
security  services.  In  addition,  in  order  to  look  at  potentials  for  better  cross  security  boundary 
handling  of  data,  the  Intelligence  Community  Security  Markup  Standard  was  applied  to  the  data 
model  of  one  of  the  capabilities.  Finally,  this  experiment  investigated  the  requirements  for  the 
development  of  an  OPSWARE  compliant  installer  for  the  infrastructure  and  select  capabilities  in 
order  to  ensure  compliance  with  DODIIS  requirements. 

Refer  to  the  IOPC-X  Software  Developer  Kit  (SDK)  for  a  thorough  review  of  all  technical 
specifications. 
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Methods,  Assumptions  and  Procedures 


Information  Operations  Planning  Capability  -  Experiment  (IOPC-X)  was  developed, 
demonstrated  and  vetted  through  a  series  of  tight  spirals  which  constituted  the  initial  AOC  SPVT 
“reference  architecture.” 

Spiral  development  was  based  on  the  results  of  capabilities-based  needs  and  requirements 
analyses  to  derive  the  AOC  Strategy  Division  and  Joint  Information  Operations  (10) 
communities  notional  reference  architecture  system  requirements  appropriate  with  the 
anticipated  future  level  of  the  hardware  and  software  constraints  facing  the  AOC  and  Joint  10 
communities. 


Operational  and  system  design  knowledge  (understanding) 

Operational  and  system  design  knowledge  (understanding)  was  obtained  through  a  collaborative 
effort  between  the  contractor  and  the  JFCOM  and  JIOWC  VisIOn  team.  First,  the  team  attended 
operational  user  forums  for  demonstration  of  planned  IOPC-X  user  interfaces  and  functionality 
and  attended  government-specified  Combatant  Command  (COCOM)  and  air  component 
meetings  to  support  development  of  Operational  and  System  Views  (SVs)  for  the  IOPC-X 
reference  architecture  in  parrallel.  Second,  at  the  Government’s  direction,  the  team  conducted 
data  collection  trips  to  determine  the  current  processes,  source  data,  inputs/outputs,  decisions, 
visualization  elements  and  software  features  critical  to  the  AOC  and  Joint  10  community.  These 
two  infonnation  elicitation  approaches  generated  artifacts  from  which  the  team  could  derive  the 
capabilities-based  needs  and  requirements  for  the  IOPC-X  system  “reference  architecture”.  The 
derived  requirements  were  communicated  to  both  industry  and  Government  stakeholders  to 
include  the  AOC  and  Joint  10  community  to  validate  the  operational  effectiveness  of  the 
analysis.  Story  boards  or  semi-operational  prototype  screens  were  used  to  present  capability  and 
functionality  “look  and  feel”  for  the  approach  to  the  client  prototypes  to  be  developed  in 
conjunction  with  the  reference  architecture. 

Special  focus  was  given  to  those  activities  specific  to  the  perfonnance  of  “Adaptive  Planning” 
and  the  “Time  Sensitive  Planning”  (TSP)  process  to  include  the  cognitive  requirements, 
perception  requirements,  comprehension  and  projection  and  their  impact  on  infonnation  display, 
ordering,  retrieval  and  other  aspects  of  information  presentation  that  impact  cognitive 
capabilities. 


AOC  and  Joint  10  requirements  collected  focused  on  : 

•  system  performance; 

•  process  control; 

•  process  decision  points; 

•  strategy  analysis  in  the  context  of  work; 

•  functional  capability; 

•  software  systems; 

•  software  applications; 
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•  collaboration  technologies; 

•  information  flow  between  internal  and  external  processes; 

•  information  flow  between  associated  systems. 

The  Software  Development  Kit  for  the  reference  architecture  included  appropriate  reference(s)  to 
each  s  ystem  r  equirement  an  d  w  as  m  aintained  t  o  cap  ture  t  he  i  ncremental  f  indings  i  dcntificd 
during  each  IOPC-X  spiral. 


Trade  Studies 

In  establishing  the  IOPC-X  development/prototype  environment,  the  team  performed  trade 
studies  to  evaluate  candidate  software  for  potential  inclusion  in  the  IOPC-X  reference 
architecture  and  IOPC-X  prototypes.  The  results  of  the  trade  studies  were  communicated  to  the 
government  stakeholder. 

The  team  began  by  researching  existing  sources  of  pertinent  scientific  and  technical  infonnation 
(STINFO)  to  detennine  the  state-of-the-art  capabilities  in  that  task  area  to  avoid  duplication  of 
effort  and  to  conserve  scientific  and  technical  resources. 

The  team  started  with  the  IWPC  Version  4.2  baseline,  the  AOC  Strategy  and  10  planning  system 
of  record,  to  provide  trade  studies  and  follow-on  implementations  including  an  ability  to  send 
and  receive  the  necessary  operational  data,  through  interoperability  of  IOPC-X  with  both 
interfacing  systems  and  internal  integration  of  candidate  operational  prototype  modules. 

The  team  maintained  DODAF  compliant  SVs,  high-level  designs,  use  cases,  and  IOPC-X 
reference  architecture  source  code  for  the  approved  architecture  changes  to  the  Government- 
designated  IWPC  Version  4.2  GFE  baseline.  The  system  design  and  interface  definitions  were 
maintained  and  published  in  the  IOPC-X  Software  Development  Kit  document.  This  document 
and  the  supporting  version  controlled  binary  distribution  of  the  framework  were  distributed  to  all 
stakeholders  on  a  regular  basis.  Backward  compatibility  was  supported  throughout  the  spiral 
evolutions. 

Where  feasible,  user  comments  were  incorporated  into  each  prototype  and  the  final  reference 
architecture  to  obtain  the  best  blend  of  user  acceptance  while  still  adhering  to  the  development 
schedule. 

The  team  evaluated  industry  wide  accessible  tools  identified  by  Government  and  711  HPW/RHC 
and  trade  study  results  associated  with  expected  critical  infrastructure  or  architecture  elements  of 
the  IOPC-X  reference  architecture  including  the  following  in  Table  1. 


Trade  Study  Results  for  Critical  Infrastructure  and  Architectural  Elements. 


Technology  Risk 

Specific  Technical  Area 

Candidates  (not  limited  to) 

Net  Centricity 

SOAP  and  Enterprise  Service 
Bus  (ESB)  tools,  UDDI 
components,  candidate  Web 
portal  and  “Web  2.0” 

SONIC  ESB  7.0; 

Systinet  UDDI  (DISA/  NESI 
project); 

Flex  2.0 
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technologies 

AquaLogic 

Websphere 

DCGS  (GOTS) 

Application  Server 
and  Database 
Extensibility 

Security  extensions,  OWL  & 
RDF 

OWL;  RDF; 

Security 

SAML;  WS-Security; 

NCES  Security  Service,  Layer  7 

Advanced  Query, 
Data  Manipulation 
Tools,  and  Common 
Data  Sharing 

XML  Schema 

transfonnations;  unstructured 
to  structured  transfonnation 

XML  Spy; 

DIA  program  (name?) 
Documentum 

Plug-in  Architecture 

Ease  of  Integration  and/or 
interoperability  with  candidate 
Operational  Tools 

ECLIPSE;  Oracle  Server 
modifications,  JAVA  enterprise 
changes  and  updating  of  IWPC 
4.2  architecture 

Multi-Level 

Security 

Evaluation  of  technologies 
applicable  to  both  Coalition 
and  system-high  solutions  that 
enable  PL-4  accreditable 
solutions,  enabling  machine- 
machine  interaction  and  multi¬ 
level  collaboration  of  strategy 
plans,  COAs  and  supporting 
analytical  data 

Oracle  OLS  &  Data  Vault, 

TNE,  etc. 

The  team  developed  automated  interfaces  capable  of  satisfying  the  required  functions 
documented  in  the  IOPC-X  system  “reference  architecture”  .  Each  automated  interface  that  was 
developed  employed  common  data  types  and  formats,  building  towards,  and  consistent  with,  the 
master  IOPC-X  “reference  architecture.” 

Prototypes  considered  included  automated  interfaces  to  systems  such  as: 

•  TBMCS  •  JTT 

•  MIDB  •  IWPC 

The  au  tomated  i  nterfaces  w  ere  also  d  eveloped  an  d  co  nfigured  t  o  o  ther  C  OTS  an  d  G  OTS 
identified  through  industry-proposed  connections,  or  module  inclusions  to  the  IOPC-X  baseline. 
Changing  interfaces  to  these  external  components  unfortunately  quickly  obsoleted  much  of  the 
progress  in  this  area. 

Integrate  IOPC-X  Enhancements  into  IWPC 

Potential  high  value  IOPC-X  enhancements  and  problem  resolution  issues  for  potential  near-tenn 
inclusion  in  the  IWPC  4.2  operational  baseline  were  identified  early  and  delivered  to  the  IWPC 
SPO.  Subsequent  toe  ustomer  pr  ioritization  a  nd  a  pproval,  t  he  t  earn  d  eveloped,  t  ested,  a  nd 
integrated  these  high  value  modifications  with  the  IWPC  4.2  operational  baseline.  The  primary 
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contribution  developed  during  this  effort  was  a  web  service  interface  for  the  existing  IWPC  4.2 
system. 

The  team  provided  recommended  markups  to  GFE-provided  IWPC  4.2  Technical  Data  to 
support  Interim  Authority  To  Operate  in  classified  test  environments  as  well  as  document  the 
above  mentioned  enhancements. 
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Results  and  Discussion 


Throughout  the  project  the  IOPC-X  architecture  was  produced  refined  and  integrated  with  two 
clients:  the  COA  Sketch  flex  based  thin  client,  and  a  OSGI  client  framework  to  support 
migration  of  existing  capabilities.  Select  components  from  the  Infonnation  Warefare  Planning 
Capability  (IWPC)  were  used  as  a  sample  codebase  for  migration.  The  results  of  the  IWPC  port 
to  the  new  architecture  included  porting  the  clients  to  the  OSGI  Rich  Client  Platform  front  end 
and  converting  the  persistence  tier  to  a  JENA  ontology  data  store  accessed  via  a  newly 
developed  web  service.  This  experiment  proved  that  legacy  systems  could  be  ported  to  the 
architecture.  The  three  IWPC  applications  selected  were  ported  at  about  a  90%  completion  state. 
The  rest  of  this  section  discusses  the  results  of  integrating  the  COA  Sketch  Visualization  tool 
with  the  IOPC-X  architecture. 

Intelligence  Community  (1C)  Information  Security  Markings  (ISM)  for 
Security  Labeling 

To  address  security  labeling,  IOPC-X  investigated  security  level  tagging  at  the  data  object  level 
in  accordance  with  the  IC  ISM  standard.  An  advantage  of  the  IC  ISM  approach  is  that  it  supports 
a  tear-line  model  for  both  untagged  text  and  tagged  data  objects.  Under  a  tear-line  model,  a 
document  is  broken  up  into  sections  that  are  classified  at  different  security  levels.  By  creating  the 
core  content  at  the  lowest  classification  level  while  amplifying  infonnation  is  contained  as 
extensions  at  higher  classification  levels,  the  more  sensitive  infonnation  is  marked  and  can  be 
stripped  off  by  trusted,  automated  processes.  This  facilitates  automated  data  exchange  and 
pennits  wider  dissemination  while  accommodating  releasability  guidelines  for  the  sensitive 
information  below  the  tear-line. 

Results 

The  first  lesson  learned  in  our  attempt  to  incorporate  IC  ISM  markings  for  every  attribute  of  the 
COA  Sketch  data  model  is  the  need  to  only  bring  across  the  classification  marking  itself  and 
allow  user  interaction  to  trigger  querying  for  the  rest  of  the  IC  ISM  details  via  a  lazy-loading 
paradigm.  This  is  largely  due  to  analysis  results  showing  less  operator  immediate  need  for  the 
detailed  classification  data.  Given  the  size  of  the  XML  data  associated  with  the  additional 
information,  further  compression  would  also  be  recommended. 

IOPC-X  Client  Architecture 

In  support  of  an  evolutionary  development  path  and  re-use  of  existing  Java™  and  .Net  developed 
“Fat  Clients”;  The  IOPC-X  design  included  an  Open  Services  Gateway  Initiative  (OSGi) 
compliant  plug-in  infrastructure  based  upon  the  Eclipse  Rich  Client  Platform.  Efforts  included 
proof-of-concepts  for  inclusion  of  .Net  clients  and  Java  client  plug-in  development. 

Client  Components 

•  IOPC-X  RCP  Workbench:  The  workbench  acts  as  a  ‘baseline’  IOPC-X  installation.  All 
client  plug-ins  use  the  workbench  as  their  target  platfonn.  It  initializes  the  main  client 
window,  menus,  and  toolbars,  providing  a  predictable  environment  for  the  plug-ins. 

•  Data  Access  plug-in:  In  an  effort  to  reduce  memory  consumption  and  network  traffic,  the 
data  access  plug-in  provides  a  single  interface  through  which  the  ontologies  can  be 
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manipulated.  Use  of  this  plug-in  is  not  mandatory  and  a  client  plug-in  could  reference 
the  web  service  interface  directly  if  so  desired. 

•  Login  &  Security  plug-in:  Authentication  routines  and  login  handling  are  integrated  into 
the  workbench  through  a  separate  plug-in.  This  plug-in  provides  the  login  infonnation  to 
any  other  plug-ins  that  need  to  access  it  (such  as  the  Data  Access  plug-in). 

•  Dynamic  Update  plug-in:  Client  plug-ins  can  be  updated  transparently  by  an  update  plug¬ 
in.  No  additional  code  needs  to  be  written  to  allow  dynamic  update  -  this  capability  is 
provided  by  the  workbench  and  the  OSGi  framework. 

Client  Component  Results 

•  The  Service-Oriented  Architecture  (SOA)  enhanced  Eclipse  RCP  based  workbench  and 
discoverable  plug-in  architecture  proved  to  be  a  viable  alternative  method  for  handling 
user  interfaces  vs.  strictly  thin  client  alternatives.  The  deployment  of  the  workbench  is 
recommended  to  be  from  a  discoverable  URL.  The  download  time  for  the  lightweight 
plug-ins  was  reasonable  for  operational  use. 

•  The  use  of  the  login  and  security  plug-in  still  requires  further  investigation  to  ensure  it 
would  pass  accreditation. 

•  The  dynamic  update  plug-in  unfortunately  was  not  used  or  tested  during  the  Limited 
utility  Assessment  or  Pirates  Dagger  event  but  shows  promise  in  supporting  the  plug-in 
UI  approach. 

•  It  should  also  be  noted  that  2.5  Dimensional  interfaces  are  not  easily  supported  at  this 
time  via  thin  client  technologies.  The  plug-in  architecture  used  here  is  a  viable  approach 
to  support  these  types  of  user  interfaces. 

In  terna  tionaliza  tion 

In  context  of  IOPC-X,  internationalization  is  focused  on  the  support  of  different  lexicons  for 
different  COIs.  IOPC-X  leveraged  its  Ontology  support  in  order  to  allow  Ontological  capturing 
of  lexicons/Vocabularies/Taxonomies  from  different  COIs  into  it’s  knowledgebase.  IOPC-X 
required  that  each  integrating  module  externalize  its  strings  into  Key  Value  pairs.  The  Keys  and 
default  value  strings  from  each  module  were  provided  in  Ontological  form  for  correlation  to  the 
COI  ontologies  mentioned  above.  Integrating  modules  then  accessed  a  listing  of  COIs  using 
IOPC-X  convenience  methods  and  provide  IOPC-X  with  a  user  selected  COI  namespace  as  well 
as  the  unique  module  namespace.  In  return  IOPC-X  provided  the  user  the  COI  overridden 
“Internationalized”  Key  Value  pair  list  for  instantiation  within  the  integrating  module. 


Results 

•  While  the  designed  and  implemented  handling  for  this  feature  worked  as  expected,  it  is 
questionable  as  to  whether  or  not  the  additional  loading  overhead  is  worth  the  limited 
enhancement  gained. 

•  To  test  this  feature  easier  administrative  views  for  manipulation  of  the  underlying 
ontologies  is  necessary  and  potentially  would  need  to  be  kept  in  context  of  the  tools  being 
manipulated. 

•  The  handling  of  this  feature  should  be  broken  out  into  a  separate  Web  Service  from  the 
IOPC-X  data  service. 
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OPSWARE  Compliant  Installer 

In  discussions  with  DoDIIS  and  OPSWARE  representatives  it  was  determined  that  the  only  real 
requirement  to  work  with  OPSWARE  and  be  DoDIIS  compliant  was  to  be  callable  as  a 
“command  file”  no  user  interaction  installer.  IOPC-X  leveraged  Installshield  as  well  as  some 
custom  scripts  and  queries  in  order  to  not  only  install  the  IOPC-X  software  itself,  but  the 
supporting  Weblogic  Application  server  and  Oracle  Database. 


Results 

•  The  combined  use  of  both  an  interactive  as  well  as  command  file  driven  installer,  allowed 
for  easier  debug  of  the  command  file  version  installation. 

•  Early  development  of  the  installer  greatly  eased  potential  greater  pressures  and  demands 
on  developers. 

•  The  installer  also  allowed  for  consistency  in  system  configuration,  making  duplication  of 
issues  easier. 


IOPC-X  Web  Service  and  Data  Access  Tier  Architecture 

Web  Ontology  Language  (OWL)  utilized  by  IOPC-X 

All  Data  Storage  in  IOPC-X  was  in  Ontology  form  in  order  to  align  with  the  DoD  Net-Centric 
Data  Strategy.  The  data  standard  followed  was  the  Web  Ontology  Language  (OWL) 
specification.  More  information  on  the  Ontology  and  OWL  specifications  can  be  obtained  from 
http://www.w3.org/2004/QWL/.  OWL  is  a  Web  Ontology  Language  that  can  define  a  semantic 
vocabulary  as  well  as  information  stored  within  that  vocabulary.  OWL  builds  on  the  RDF 
schema  (http://www.w3.org/RDF/)  which  is  an  XML  (extensible  Markup  Language) 
representation  of  a  vocabulary  or  ontology  that  contains  classes  and  properties.  OWL  adds  the 
ability  to  describe  relationships  between  classes  within  any  ontology.  OWL  is  a  way  to  represent 
data  models  and  data  stored  within  data  models  with  all  the  data  descriptions  of  XML  schema, 
all  the  resource  definitions  of  RDF,  and  the  ability  to  tie  data  models  together  with  the  OWL 
specifications 

Results 

•  The  use  of  this  standard  did  not  present  any  major  issues  in  and  of  itself,  but  the 
supporting  tools  and  libraries  for  working  with  this  standard  have  proven  to  still  be 
immature  at  this  point  in  time. 

•  The  specification  for  the  ontology  technology  sets  are  well  thought  out  but  still  maturing 
themselves.  (Such  as  the  XML  SPARQL  result  specification  that  came  out  this  year) 


Ontology  Libraries  utilized  by  IOPC-X 

The  project  researched  JENA  and  SESAME  Open  source  library  kits  for  Ontology  data.  These 
were  the  two  forefront  standards  compliant  libraries  for  ontology  data  at  the  time.  JENA 
outperfonned  SESAME  on  a  couple  of  fronts  including  persistence  to  an  Oracle  database. 
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The  open  source  JENA  (version  2.5.4)  library  is  used  within  the  IOPCDataAccessBean  to  store, 
load  and  manipulate  Ontology  data  models  and  their  data.  More  information  on  the  JENA  library 
can  be  obtained  here:  http://jena.sourceforge.net/.  The  license  for  the  JENA  library  can  be 
obtained  here:  http://jena.sourceforge.net/license.html .  Jena  is  built  on  top  of  other  sub-systems 
or  libraries,  the  information  on  the  libraries  and  their  respective  licenses  can  be  obtained  here: 
http://jena.sourceforge.net/Licenses/index.html . 

Results 

•  The  Jena  open  source  library  was  used  for  the  Ontology  data  manipulation  and 
persistence.  This  library  persist  the  ontology  data  models  within  a  SQL  database,  but  the 
normalization  and  table  setup  for  Jena  to  persist  data  was  not  optimum  and  caused  delays 
in  retrieving  and  querying  models. 

•  These  open  source  libraries  cannot  compete  when  it  comes  to  data  persistence  to  the  likes 
of  a  Relational  Database  (RDB)  that  has  had  years  to  mature  and  optimize  response  time. 
These  ontology  technology  implemented  library  solution  sets  proved  immature.  One  key 
area  in  which  they  are  lacking  is  in  easy  support  for  data  validation.  Another  area  is  in 
handling  cascading  deletes  and  orphaned  nodes. 

•  The  commercial  world  continues  to  work  these  issues.  Bringing  to  bear  its  resources  and 
some  time  to  optimize  the  Ontology  persistence  and  querying  capabilities,  the  use  of 
these  technologies  will  most  likely  be  viable  in  the  next  several  years.  Early 
implementers  of  this  technology  will  take  on  large  risks  unless  potential  alternate  fallback 
paths  at  appropriate  abstraction  layers  are  maintained. 

TM 

Stateless  Session  Enterprise  Java  Bean  (EJB) 

The  IOPCDataAccessBean  is  deployed  to  a  Bea  Web  Logic  Application  Server  version  10 

TM  TM  TM 

maintenance  pack  1  or  higher.  The  Sun  1.5  Java  Development  Kit  (JDK  )  and  J2EE  5  with 

TM  TM 

EJB  3.0  are  used  to  create  and  run  the  IOPCDataAccessBean  EJB  .  The  Sun  licenses  for  these 
can  be  obtained  here:  (http://www.java.com/en/download/license.jsp).  The  bean  also  utilizes  the 
Apache  XML  Xerces  library  (xerceshnpl.jar)  version  2.7.1  to  perform  data  manipulation  from 
ontology  OWL  format  to  a  plain  XML  fonn  when  necessary.  More  information  on  the  Apache 
XML  Xerces  project  can  be  obtained  here:  http://xerces.apache.org/xerces2-j/.  The  license  for 
this  Apache  library  can  be  obtained  here:  http://www.apache.Org/licenses/LICENSE-2.0.html. 

The  IOPC-X  IOPCDataAccessBean  was  developed  as  a  Stateless  Session  EJB™.  This  bean 

TM  TM 

adheres  to  the  J2EE  5  and  EJB  3.0  specification  utilizing  annotations  in  place  of  deployment 
descriptors  (http://java.sun.com/produ  cts/ejb/docs.html).  This  EJB  will  run  within  a  Bea 
Web  Logic  Application  Server  version  10  maintenance  pack  1  or  higher 

(http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/weblogic&WT.ac= 

topnav  products  weblogic).  This  application  server  utilizes  the  Sun  Java  Runtime 
Environment  (JRE)  1.5  and  the  Sun  J2EE™  5  with  EJB™  3.0  specifications.  This  EJB™  will 
theoretically  deploy  to  any  J2EE  application  server  that  supports  the  aforementioned 
specifications  although  all  testing  has  been  done  with  the  WebLogic  Application  Server.  The 
IOPCDataAccessBean  is  accessible  via  RMI  and  can  be  looked  up  on  the  application  servers 
Java  Naming  and  Directory  Interface  (JNDI)  with  the  JNDI  name  of:  IOPCDataAcess/remote  for 

TM  .  .  TM 

outside  the  J2EE  container  and  IOPCDataAccess/local  for  within  the  J2EE  container.  This 
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EJB  is  the  actual  core  of  the  IOPC  Data  tier  where  the  IOPC-X  web  service  interface  is  a  Facade 
onto  this  interface. 

Results 

•  The  Stateless  nature  and  proven  use  over  many  years  for  scalability  proved  to  be  fairly 
crippled  in  use  due  to  the  lack  of  a  solid  optimized  query  handling  in  the  backend.  Due  to 
the  deficiencies  found  in  the  Jena  solution  set  discussed  above,  client  access  to  data  was 
slow  at  best. 

•  The  use  of  this  part  of  a  well  known  n-Tiered  architecture  did  continue  to  provide 
benefits  from  the  hosting  application  server  in  authentication  and  authorization  handling, 
connection  pool  handling  and  potentials  for  clustering  for  scalability. 

Data  Storage 

The  IOPCDataAccessBean  utilizes  a  JDBC™  Data  Source  within  the  application  server  to  store 
the  ontology’s  and  data  into  a  JDBC  compliant  database.  All  testing  has  been  done  with 
MySQL®  5  and  Oracle  lOg  databases.  The  IOPCDataAccess  JDBC™  data  source  is  configured 

TM  .  .  .  .  TM 

within  the  J2EE  application  server.  More  information  on  J2EE  Data  Sources  can  be  obtained 
from  the  Sun  J2EE  1 .5  specifications. 

Results 

The  data  storage  perfonned  as  expected,  however,  the  lack  of  optimization  in  data  handling  by 
JENA  impacted  the  performance  of  retrieval. 


IOPC  Data  Access  Web  Services 

The  IOPC  Data  Access  Web  Services  programming  model  centers  on  Java™  Web  Service  (JWS) 
files  and  annotations.  The  standard  @WebService,  @WebMethod,  and  @SOAPBinding  JWS 
annotations  are  used  (annotations  were  introduced  in  Version  5.0  of  the  JDK  ,  specified  by  JSR- 
175),  and  include  annotations  defined  by  the  Web  Services  Metadata  for  the  Java  Platform 
specification  JSR  181  (Web  Services  Metadata  for  Java  Platform). 

The  Web  Service  is  hosted  in  Axis2  and  is  implemented  using  standard  J2EE™  components,  as 
defined  by  the  Implementing  Enterprise  Web  Services  1.1  specification  JSR-921,  which  is  the 
1.1  maintenance  release  of  JSR-109.  See  Enterprise  Web  Services  1.1. 

Currently,  the  web  service  is  targeted  to  run  inside  of  Axis2,  but  it  could  compile  and  run  under 
any  standard  J2EE  application  server  that  supports  JWS  files  and  annotations. 

For  the  mapping  of  the  web  service  to  the  SOAP  Message  Protocol  the  JWS  file  uses  the 
standard  @SOAPBinding  annotation,  at  the  class  level,  to  specify  the  SOAP  bindings  of  the  web 
service,  such  as  ‘RPC-encoded’  or  ‘document-literal/wrapped’.  The  IOPC  Data  Access  web 
service  uses  the  ‘document-literal/wrapped’  style  encoding.  Document/literal  is  WS-I  compliant, 
and  the  wrapped  pattern  meets  the  WS-I  restriction  that  the  SOAP  message's  “soap:body”  has 
only  one  child. 
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Axis2  web  services  use  SOAP  as  the  message  format  and  Hypertext  Transfer  Protocol  as  the 
connection  protocol;  both  versions  1 . 1  and  1 .2  are  supported.  See  SOAP  1.1  and  1.2. 

The  IOPC-X  web  service  uses  WSDL  1.1.  See  the  WSDL  1.1  specification. 

Results 

•  This  standardized  approach  to  Web  Service  Implementation  has  proven  to  be  a  solid 
approach. 

•  Automated  tools  for  WSDL  generation  are  still  lacking  in  their  performance  and  it  is 
highly  recommended  that  WSDLs  be  created  by  hand  in  order  to  ensure  proper 
generation. 


Model  Registration 

Data  storage  and  data  manipulation  within  the  IOPC-X  software  suite  go  through  the 
IOPCDataAccess  interface.  Each  application,  upon  installation  into  the  suite,  needs  to  register 
their  data  model  with  the  IOPCDataAccess  interface.  The  data  model  is  registered  by  providing, 
in  ontology  form,  an  OWL  formatted  description  of  that  model.  Each  application  will  has  a 
unique  model  name  under  which  the  model  is  registered.  This  model  name  is  almost 
synonymous  with  a  database  schema  name  and  is  used  by  clients  when  obtaining  and 
manipulating  data  within  the  model. 

Model  registration  (upon  application  installation)  is  performed  through  a  call  to  the 
IOPCDataAccessBean.  Each  application’s  model  or  general  ontology  vocabulary  can  be  loaded 
into  the  IOPCDataAccess  bean  via  the  registerModel  method.  This  method  takes  the  Ontology 
OWL  XML  (model)  description  within  a  String  parameter,  as  well  as  the  ontology  name  for  it  to 
be  stored  under,  and  a  String  parameter  indicating  the  Semantic  Language  the  ontology  is  in.  The 
languages  the  ontology  can  be  described  in  are  "RDF/XML",  "N-TRIPLE"  and  "N3".  More 
information  on  any  of  these  ontology  data  formats  can  be  found  here: 
http://www.w3.Org/TR/2004/REC-rdf-testcases-20040210/#ntriples  ,  or  here: 
http://iena.sourceforge.net/tutorial/RDF  APEindex.html. 

Results 

•  While  this  approach  worked,  it  lead  to  a  centralized  knowledge  store  and  processing  point 
for  the  infrastructure  and  thus  increased  latency. 

•  While  ontology  retrieval  from  disparate  end  points  is  supported  by  the  standards  and 
libraries,  decentralized  processing  of  queries  is  not  supported. 


XML-Legacy  Model  Registration 

For  legacy  XML  based  applications  or  applications  not  using  any  semantic  ontology  capabilities 
a  process  has  been  established  that  can  take  plain  XML  Schema  Definition  (XSD)  and  convert  it 
to  an  OWL  representation  of  that  XSD  that  can  then  be  registered  with  the  IOPCDataAccess 
bean.  This  way  the  data  for  that  system  can  be  stored  within  the  IOPC  Data  Store  in  an  ontology 
form  that  can  be  utilized  by  other  applications  while  the  application  can  utilize  the  XML  data 
model  that  the  application  was  built  around.  The  application  can  perform  data  manipulation  and 
receive  change  data  notifications  via  JMS  in  an  XML  format. 
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Results 

•  This  process  entails  using  one  of  the  many  Graphical  User  Interface  (GUI)  tools  on  the 
market  that  can  take  XSD  and  create  a  simplistic  OWL  representation  of  that  XSD.  One 
tool  that  has  this  functionality  is  the  TopBraid  Composer.  There  are  other  applications 
that  have  this  functionality.  For  more  infonnation  on  the  TopBraid  Composer  visit  the 
website  at:  http://www.topbraidcomposer.com/. 

•  These  tools  will  create  a  first  cut  of  the  OWL  representation  of  the  model.  These  tools  do 
not  convert  all  of  the  XML  syntax  over  to  OWL  accurately.  The  developer  will  have  to 
go  through  the  ontology  that  is  built  in  an  ontology  editor  and  fix  the  ontology  to 
accurately  reflect  the  model,  (i.e.  the  xsxhoice  XML  sytax  doe  not  convert  well  into 
ontology  form  with  these  tools) 


Data  Retrieval 

Once  a  data  model  for  an  application  is  registered,  data  retrieval  or  loading  existing  data  from  a 
data  model  is  accomplished  with  the  getData  method  in  the  IOPCDataAccessBean.  This  method 
will  return  a  String  XML  representation  of  the  requested  data  in  the  result  set  format  specified  by 
the  dataXMLLanguage  parameter.  The  getData  method  will  take  a  SPARQL  query  that  will  be 
used  to  query  the  data  from  the  existing  data  model.  More  information  on  the  SPARQL  query 
language  can  be  obtained  here:  http://www.w3.org/TR/rdf-sparql-querv/  and  a  good  tutorial  for 
the  SPARQL  query  language  can  be  found  here  http://jena.sourceforge.net/ARQ/Tutorial 

The  getData  method  has  the  following  parameters:  modelName,  SparqlQuery, 
dataXMLLanguage,  and  User  Identification  (userid).  The  modelName  is  a  String  parameter  that 
holds  the  name  of  the  model  to  retrieve  data  from.  The  SparqlQuery  String  parameter  in  the 
getData  method  is  the  query.  The  dataXMLLanguage  parameter  is  a  String  that  defines  what 
format  the  result  set  string  that  is  returned  is  in.  Valid  formats  are:  “XML”,  “RDF/XML”,  “N- 
TRIPLE”,  and  “N3”.  “RDF/XML”  is  the  preferred  format.  More  information  on  any  of  these 
ontology  data  formats  can  be  found  here:  http://www.w3.org/TR/20Q4/REC-rdf-testcases- 
200402 1  Q/#ntriples  ,  or  here:  http://iena.sourceforge.net/tutorial/RDF  APEindex.html.  The 
userid  is  a  String  holding  the  userid  of  the  user  that  is  requesting  the  data. 

The  other  getData  method  takes  all  the  above  methods  parameters,  except  a  string  array  of  object 
GUID’s  replaces  the  SPARQL  query  parameter.  This  getData  method  will  return  an  ontology 
model  triplet  form  of  the  data  instead  of  a  result  set  form  of  the  data. 

Results 

•  IOPC-X  attempts  to  compile  a  simplistic  translation  to  XML  in  the  IOPC  DataAccess 
layer  was  a  resounding  failure.  The  interface  could  not  be  kept  generic  enough.  It 
became  exceedingly  difficult  to  support  all  the  xml  specified  elements  such  as  key  refs, 
refs,  etc. 

•  COA  Sketch  attempted  to  translate  the  SPARQL  query  XML  result  sets  into  a  coa  sketch 
XML  so  the  clients  could  understand  the  data.  This  prohibited  the  clients  from  using  any 
of  the  power  of  the  ontology  technology,  created  a  time  consuming  middle  tier  to  go 
through,  and  defeated  the  purpose  of  utilizing  the  ontology  data  formats.  If  you’re 
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writing  a  client  to  persist  the  data  in  ontology  fonnat  you  need  to  make  the  client 
understand  the  ontology  formats. 

•  There  is  a  difference  between  SparQL  Result  set  and  an  ontology  model.  When  a  client 
retrieved  a  SparQL  result  set  in  any  fonnat  xml,  rdf  or  java  object  resource,  it  didn’t  have 
any  of  the  model  infonnation  just  a  result  set  from  a  query.  Jena  had  no  way  of  adding 
this  result  set  into  an  existing  ontology  model  for  use  by  the  client.  In  order  to  load  an 
ontology  into  memory  you  have  to  retrieve  the  whole  model  and  load  it  up  into  a  Jena 
memory  ontology  and  then,  using  java  ontology  objects,  add  or  merge  the  two.  Solving 
this  issue  will  be  key  to  using  SparQL  result  sets  for  data  handling  especially  when 
middle  tier  business  logic  needs  to  be  applied  and  expecting  to  have  all  the  power  of  the 
semantic  specs. 

•  Creating  each  set  of  saved  data  as  its  own  stand  alone  ontology  would  allow  your  client 
to  have  a  JENA  like  library  in  it  and  utilize  all  the  aspects  of  an  ontology  library,  but  this 
makes  linking  data  from  one  applications  data  model  to  another’s  exceedingly  difficult 
and  querying  the  data  even  slower. 


Data  Manipulation  and  Transaction  Handling 

Data  manipulation  is  done  through  the  manipulation  methods  within  the  IOPCDataAccessBean. 
The  interface  accepts  dataXML,  userid,  modelName,  parentGUID,  and  dataXMLLanguage  and 
returns  an  XML  String.  The  dataXML  is  a  String  parameter  that  holds  the  data  to  be  stored, 
modified  or  deleted.  The  userid  is  a  String  parameter  used  by  the  bean  to  verify  that  the  user  has 
the  attribute  lock  for  the  data  to  be  modified.  The  modelName  is  a  String  parameter  that  holds 
the  name  of  the  model,  this  is  the  same  name  the  application  registered  the  data  model  with  in 
the  model  registration  process  during  initial  installation.  The  parentGUID  parameter  is  a  String 
holding  the  GUID  of  the  parent  data  object  of  the  data  being  added  to  the  model.  This  parameter 
is  only  used  in  the  addElement  method  and  is  only  needed  if  the  parent  relationship  is  not  held 
within  the  dataXML.  The  dataXML  String  can  contain  any  number  of  data  objects  and  these  can 
be  related  to  an  already  existing  data  object  in  the  IOPC  Data  Store.  The  dataXMLLanguage 
parameter  is  a  String  that  defines  what  fonnat  the  dataXML  is  in.  Valid  formats  are:  “XML”, 
“RDF/XML”,  “N-TRIPLE”,“N3”,  and  XML.  “RDF/XML”  is  the  preferred  fonnat. 

The  GUID  or  unique  resource  identifier  for  each  data  object  to  be  stored  is  an  important  attribute 
in  the  dataXML.  For  each  data  object  element  contained  in  the  dataXML  there  is  a  GUID  that 
must  be  generated  by  the  client  and  must  adhere  to  the  specifications  in  the  IOPC-X  SDK  for 
conelation  to  the  register  model. 

Upon  successful  completion,  the  add  and  modify  methods  return  the  String  XML  representation 
of  the  objects  passed  into  the  method  in  the  format  specified  by  the  dataXMLLanguage 
parameter.  The  delete  method  returns  a  Boolean  TRUE  upon  successful  completion  of  the  delete. 
Both  methods  throw  an  exception  if  the  data  manipulation  is  not  successful.  The  methods  throw 
an  IOPCPropertyLockException  if  there  was  a  data  lock  issue. 

The  Update  Tripplets  service  is  a  transactional  data  manipulation  that  can  add,  modify  and  delete 
Ontology  triplets  in  the  IOPC-X  Datastore.  As  with  the  other  data  manipulation  services  the 
name  of  the  model  to  be  manipulated  is  passed  in  as  well  as  a  XML  String  describing  the 
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requested  transaction.  A  client  can  perform  any  number  of  data  manipulations  within  one 
transaction.  The  method  will  return  a  transaction  number  which  is  referenced  in  update 
notifications  sent  out  by  the  IOPC-X  server. 

Results 

•  The  IOPC-X  transactional  XML  that  allowed  one  to  add  mod  and  del  in  one  call  was 
simple  XML.  Unlike  in  JDBC  where  you  can  have  a  java  object  called  a  prepared 
statement  this  XML  didn’t  do  enough  validation  on  what  went  into  it  so  information  in  a 
text  box  such  as  <  >  and  other  xml  characters  could  corrupt  the  transaction.  JDBC  to  a 
RDB  deals  with  this  by  utilizing  the  prepared  statement  class.  IOPCX  ended  up  doing  it 
at  the  client  Level  in  IWPC  checking  over  the  input  before  it  went  into  the  transaction 
xml  but  it  would  be  nice  to  have  a  small  connectivity  kit  that  would  have  done  this  for 
you.  This  kit  would  have  to  be  available  for  all  supported  Web  Service  programming 
languages 

•  String  being  passed  around  between  client  and  server  for  web  service.  At  some  point  you 
will  Reach  the  limit  of  String  and  have  problems  passing  data.  So  when  passing  Strings 
back  from  a  web  service  you’d  need  a  way  to  stream  it  or  cover  this  limit  on  what  size  of 
serializable  String 

•  The  locking  mechanism  was  relatively  simple  in  nature  but  perfonned  well  at  the  PD 
Event.  The  simplistic  locking  mechanism  that  included  a  timer  on  an  entity  bean  with  a 
web  service  call  to  lock  and  unlock  worked  very  well  in  various  ways  by  different 
clients.  This  was  an  easy  effective  cheap  way  to  implement  locking. 

•  Further  investigation  into  the  benefits  or  detriments  of  attribute  level  locking  on  a 
collaborative  interface  has  yet  to  be  accomplished. 


Data  Change  Notification 

IOPC-X  investigated  the  use  of  the  NCES  Web  Service  Eventing  (WSE)  based  messaging 
system  for  data  propagation.  As  an  interim  solution,  Data  Change  notifications  were  sent  from 
the  IOPCDataAccessBean  via  Java  Message  System  messages  in  the  fonn  of  OWL  Triplets  and 
in  the  form  of  plain  XML.  More  information  on  JMS  can  be  obtained  here: 
http://iava.sun.com/products/ims/. 

The  Data  Change  Notification  JMS  messages  mimic  the  document  literal  Web  Service  interfaces 
by  sending  JMS  TextMessages  with  the  following  properties: 

Change  Notification  JMS  TextMessages  Properties 

modelName  the  model  name  the  data  manipulation  took  place  in. 

Userid  the  userid  for  the  user  that  modified  the  data 

Type  ‘ADD  ’ ,  ’DELETED  ’ ,  ’MODIFICATION’ . 

When  subscribed  to  the  JMS/IOPCDataAccessOWLTopic  the  text  message  in  the  JMS 
TextMessage  contains  the  added  or  modified  data  in  the  RDF/XML  format.  When  subscribed  to 
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the  JMS/IOPCDataAccessXMLTopic,  the  text  message  in  the  JMS  TextMessage  contains  the 
XML  representation  of  the  added  or  modified  data  objects  that  adheres  to  that  models  original 
XML  XSD.  In  the  delete  case  both  messages  depict  the  data  objects  that  have  been  deleted  in 
their  respective  formats. 

Results 

•  The  use  of  JMS  within  IOPC-X  proved  fairly  reliable  with  the  exception  of  some 
duplicate  messages  being  accidently  generated  due  to  a  few  coding  errors. 

•  The  NCES  WSE  messaging  interface  proved  feasible,  but  due  to  instability  of  the 
development  network  could  not  be  fully  tested 


Change  History 

The  getChangeHistory  method  returns  an  xml  representation  of  the  change  history  on  the  guids 
passed  into  the  method  via  the  guids  string  array  parameter. 

Results 

•  The  change  history  interface  was  not  robust  enough  to  fully  support  Data  Versioning 

•  Data  Versioning,  the  bad  words  on  any  software  projects  that  has  a  relational  data  setup 
already  up  and  running  requires  further  investigation  with  regard  to  handling  using  an 
ontology  store.  Using  the  change  history  feature  to  obtain  Data  Versioning  would  have 
been  costly. 

•  Data  Versioning  should  be  a  well  thought  out  approach  at  the  early  stages  of  the 
infrastructure  design  and  warrants  early  proof-of-concepts 

•  Key  human  factors  in  the  areas  of  Undo/Redo  as  well  as  legacy  and  future  version 
support  hinge  on  this  capability 


IOPC-X  WebService  Security 

IOPC-X  investigated  the  use  of  the  NCES  recommended  WebService  Security  as  provided  by 
the  Layer  7  solution.  All  testing  was  perfonned  using  the  NCES  developmental  test  network. 

According  to  NCES  policy,  service  providers  will  need  to  provide  the  notions  of  Policy 
Enforcement  Point  (PEP),  a  Policy  Decision  Service  (PDS),  a  Policy  Retrieval  Service  (PRS), 
and  an  optional  local  Attribute  Service  (AS)  with  the  support  of  Attribute  Based  Access  Control 
(ABAC). 

A  PEP  (NCES  Service  Security  Interface  Specification  for  Service  Security  vO.4.6,  August,  13, 
2007)  is  a  SOAP  Node  that  enforces  policy  between  a  service  consumer  and  a  service  provider. 
The  PEP  is  responsible  for  requesting  authorization  decisions  from  a  PDS  and  enforcing  them. 
The  PDS  could  be  located  locally  as  a  function  of  the  PEP.  The  PEP  is  also  responsible  for 
rejecting  service  provider  service  requests  that  are  unknown,  that  contain  improperly  formulated 
SOAP  message  security  headers,  or  that  contain  un verifiable  digital  signatures.  The  PEP  is  the 
point  of  presence  for  access  control  and  must  be  able  to  intercept  all  service  requests  between 
service  consumers  and  IOPC-X  service  providers  and  cannot  be  bypassed. 
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A  PDS  (NCES  Service  Security  Interface  Specification  for  Service  Security  vO.4.6,  August,  13, 
2007)  ensures  that  a  consumer  can  consume  all  services  controlled  by  the  PDS.  The  PDS  is  the 
implementation  of  the  policy  engine,  it  works  based  on  policy.  Policy  is  key  because  it  is  used  to 
detennine  whether  a  consumer  is  authorized  to  consume  a  service.  The  PDS  serves  as  a  Security 
Assertion  Markup  Language  (SAML)  authorization  authority  for  service  providers  who  choose 
to  use  an  external  Policy  Decision  Point  (PDP).  It  accepts  authorization  queries  and  returns 
authorization  decision  assertions,  all  conforming  to  the  SAML  Protocol.  The  heart  of  the  service 
is  a  policy  evaluation  engine,  which  applies  policies  based  on  a  variety  of  inputs  such  as  the 
target  resource,  the  action  (operation)  requested,  and  the  identity  of  the  requester. 

The  PRS  (NCES  Service  Security  Interface  Specification  for  Service  Security  vO.4.6,  August, 

13,  2007)  exposes  security  policies  in  Extensible  Access  Control  Markup  Language  (XACML) 
format. 

The  NCES  AS,  based  on  Joint  Enterprise  Directory  Service,  provides  attributes  on  consumers  of 
IOPC-X  web  services  which  can  be  consumed  by  PDP  and  PDS. 

ABAC  (NCES  Sercice  Security  ABAC  Policy  Tool  v0.2  User  Guide,  October  5,  2007)  can  not 
only  encompass  Role  Based  Access  Control  rules  but  also  Identity  Based  Access  Control.  ABAC 
is  supported  by  NCES  through  two  enterprise  level  services  which  are  the  Robust  Certificate 
Validation  Services  (RCVS)  and  the  AS.  RCVS  provides  consumers  with  the  ability  to  validate 
certificates  which  have  been  presented  for  authentication.  The  AS  provides  attributes  on  people 
which  can  be  consumed  by  a  PDP  or  PDS.  These  two  enterprise  level  services  provide 
capabilities  which  when  used  with  a  PDS  or  PDP  support  ABAC. 

As  a  critical  part  of  the  NCES  Service  Security  capability,  a  PEP  has  historically  been  provided 
in  the  form  of  a  software  component  known  as  NCES  Service  Security  Development  Kit.  Until  a 
couple  of  years  ago,  hardware  based  solutions  to  implement  the  functionality  of  a  PEP  were  not 
available.  Then  vendors  like  IBM,  Jericho  Systems,  Layer7  came  up  with  devices  that  are,  SOAP 
and  XML  aware  firewalls  which  support  standards  based  web  service  message  authentication 
and  authorization,  encryption  functions,  content  validation  and  transformation,  and  message 
routing. 

These  hardware  devices  sit  in  the  path  of  the  request,  thereby  allowing  them  to  act  as  the  PEP. 
This  is  a  hardware  implementation  of  a  PEP,  whereas  the  preceding  implementation  of  the  PEP, 
the  NCES  Service  Security  Development  Kit,  was  a  software  PEP.  The  Security  Development 
Kit  achieves  the  same  effect  by  deploying  message  handlers  in  front  of  the  protected  service, 
each  message  handler  then  communicates  request  data  to  the  Service  Security  services  to 
establish  authentication  and  authorization  decisions. 

NCES  is  leaning  more  towards  Commercial  Off-The-Shelf  (COTS)  vs.  Government  Off-The- 
Shelf  (GOTS)  products  or  solutions.  They  are  also  recommending  the  use  of  PEP  firewalls  as 
compared  to  software  component  based  PEP.  NCES  has  learned  that  NCES  Service  Security 
PEP  firewall  hardware  configurations  exceed  the  software  based  PEPs  developed  using  the 
NCES  Service  Security  Development  Kit.  Using  the  NCES  Conformance  Test  Kit  and  the  NCES 
Service  Security  PEP  specification,  NCES  has  experienced  potential  performance  gains  by 
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implementing  the  NCES  Service  Security  PEP  on  a  separate  dedicated  device  with  hardware 
support  for  common  Web  service  security,  verification,  and  processing  functions. 

As  a  result,  NCES  has  deprecated  its  NCES  Service  Security  Development  Kit,  and  is 
encouraging  the  use  of  COTS  solutions  instead.  NCES  is  also  leaning  towards  using  PEP 
firewall  vs.  software  component  based  PEP  for  the  following  reasons: 

•  The  PEP  firewall  implements  a  common  PEP  instead  of  each  provider  having  its  own 
integrated  PEP 

o  Instead  of  service  consumers  accessing  service  providers  directly,  consumers  access 
providers  through  the  PEP  firewall 

•  Separating  the  PEP  from  the  service  providers  allows  a  much  greater  degree  of  freedom  in 
creating  and  deploying  services 

•  Service  providers  can  be  implemented  on  any  software  platform  and  are  no  longer  restricted 
to  the  platforms  for  which  PEP  components  are  provided 

Following  NCES  policies  IOPC-X  web  services  end  points  whether  on  AXIS  and/or  Weblogic 
require  a  hardware  based  PEP  SOAP  and  XML  aware  firewall  to  enforce  authentication  and 
authorization. 

Results 

•  Though  the  documentation  for  use  of  the  NCES  security  and  other  services  was  lacking  at 
the  time,  the  IOPC-X  team  was  able  to  work  with  the  infrastructure. 

•  The  key  problem  in  the  proposed  Layer  7  product  was  that  it  did  not  properly  support 
imported  WSDLs  as  realized  upon  using  this  product  against  the  NCES  UDDI  registry.  A 
separate  report  holding  details  of  these  findings  is  available. 

•  Another  identified  issue  with  the  proposed  NCES  solution  is  that  it  is  system  focused  and 
thus  does  not  allow  for  user  transaction  handling  by  default. 

•  For  event  experimentation  purposes,  the  NCES  environment  was  not  available.  IOPC-X 
was  rapidly  redesigned  to  leverage  the  Authentication  services  provided  by  the  Weblogic 
Application  server.  This  design  would  need  stringent  review  to  ensure  accreditation 
requirements  are  met,  however,  the  capabilities  provided  by  the  application  server  show 
potential  for  compliance. 
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Conclusions 


The  intention  of  this  section  is  to  discuss  design  issues  surrounding  the  integration  of  ontological 
data  stores  into  enterprise  applications.  The  Java  2  Enterprise  Edition  (J2EE)  platform  is  the 
primary  focus  for  integration  issues.  Design  recommendations  are  based  on  the  project’s 
experiences  with  IOPC-X/COASketch  as  well  as  industry  best  practices. 


Data  Integrity 

Any  data  store  that  provides  concurrent  access  to  multiple  clients  must  be  able  to  isolate  client 
transactions  from  one  another.  If  two  clients  try  to  access  the  same  field  simultaneously,  the  data 
store  must  provide  an  arbitration  mechanism.  The  alternative  is  a  “last  input  wins”  system,  which 
has  serious  risks  for  data  integrity. 

The  simplest  approach  to  managing  concurrency  and  exclusivity  is  to  require  the  client 
application  to  explicitly  request  exclusive  access  or  “lock”  a  resource.  This  approach  is  difficult 
to  apply  in  complex  situations  where  large  numbers  of  resources  may  need  to  be  accessed. 
Transaction  management  is  a  more  sophisticated  approach  that  shifts  some  of  the  resource 
management  burden  from  the  client  to  the  data  store. 


Explicit  Locking 

Explicit  locking  of  objects  or  object  attributes  possibly  the  simplest  approach  to  managing 
concurrency.  In  most  implementations,  a  lock  is  associated  with  every  individual  lockable 
resource.  Multiple  locking  levels  are  defined  on  the  lock  to  provide  multiple  levels  of  constraints 
on  concurrent  access. 

For  example,  if  an  object  is  “read-locked”  by  a  process,  other  processes  may  be  able  to  acquire 
read-locks.  However,  no  process  could  acquire  the  ability  to  write  to  the  object  using  a  “write- 
lock”.  In  other  words,  read-locks  provide  a  non-exclusive  guarantee  that  the  data  being  read  will 
not  change  while  the  read-lock  is  held.  Write-locks  provide  an  exclusive  guarantee  that  only  the 
holder  of  the  lock  can  change  the  data  while  the  lock  is  held.  This  is  a  simplified  example; 
locking  constructs  are  both  complex  and  subtle. 

The  primary  disadvantage  of  explicit  locking  is  that  client  software  must  acquire  and  manage 
locks.  When  the  system  of  objects  and  interactions  becomes  complex,  lock  design  and 
management  becomes  difficult  to  implement  in  client  code.  Lock  management  quickly  becomes 
an  excessive  burden  unless  the  structure  of  the  locks  is  tightly  coupled  to  the  business  logic  by 
providing  special-purpose  locks  for  specific  business  tasks.  Obviously,  this  approach  is  not 
feasible  for  general-purpose  data  stores  or  applications  where  scalability  is  an  issue. 


D-24 


Transaction  Management 

A  more  efficient  and  flexible  approach  to  concurrency  is  for  the  data  store  to  provide  a 
transaction  interface.  The  client  sends  multiple  requests  to  the  data  store  to  read  or  write  data  in 
the  context  of  a  single  transaction.  The  data  store  manages  a  private  set  of  locks  at  a  row  or 
object  level  that  provide  certain  guarantees  of  isolation  for  all  the  requests  in  the  transaction.  If  at 
any  point  a  request  fails,  the  client  or  the  server  can  issue  a  “roll-back”  command,  which 
guarantees  that  no  changes  to  the  data  store  are  recorded  as  a  consequence  of  the  transaction. 

Transaction  management  and  processing  has  become  a  standard  feature  of  enterprise 
applications.  This  is  in  part  because  it  greatly  simplifies  data  access.  Clients  need  only  manage  a 
single  transaction  object  rather  than  a  plethora  of  locks  and  locking  levels. 

As  described  below  in  Section  0,  the  Java  2  Enterprise  Edition  (J2EE)  platform  specifies  the  Java 
Transaction  API  (JTA)  as  the  standard  interface  for  transaction  management.  By  implementing 
the  JTA  interfaces,  a  data  source  allows  both  the  application  server  and  client  applications  to 
manage  transactions  in  a  standardized  fashion.  The  application  server  can  often  manage  JTA 
transactions  without  any  explicit  direction  on  the  part  of  client  applications,  leading  to  clean 
separations  between  business  logic  and  resource  allocation  code. 

The  JTA  incorporates  the  XA  two-phase  commit  standard.  Two-phase  commit  is  a  transaction 
algorithm  that  permits  multiple  data  stores  to  participate  in  a  single  transaction.  At  the  end  of  the 
transaction,  when  all  the  data  stores  have  been  updated,  the  client  sends  a  “prepare”  request.  Data 
stores  respond  to  the  prepare  request  be  committing  the  transaction,  but  leaving  the  possibility  of 
readily  rolling  it  back.  If  any  data  store  fails  to  prepare  the  changes,  the  transaction  manager 
sends  the  roll  back  command.  Otherwise,  a  final  commit  message  is  sent,  ending  the  transaction. 
Implementation  of  the  XA  portion  of  the  JTA  interface  is  vital  for  an  enterprise  data  store. 
Without  two-phase  commit  capability,  transactions  cannot  span  multiple  data  stores  and 
applications  will  be  hindered  from  accessing  multiple  data  sources. 


Transaction  Optimism  and  Granularity 

In  general,  best  practice  indicates  that  optimistic  concurrency  (use  of  unlocked  reads)  is  favored 
over  pessimistic  concurrency  (locked  reads)  in  distributed  systems  because  of  the  high  latency 
and  risk  of  client  failure.  Obviously,  this  is  true  up  to  a  point,  but  mission-critical  applications 
must  rigorously  enforce  data  integrity.  Fortunately,  the  rational  for  optimistic  concurrency  on  the 
part  of  clients  dove-tails  nicely  with  another  principle  of  distributed  client  design  -  the  task-  or 
document-oriented  service  interface.  This  suggests  that  servers  should  expose  coarse-grained 
interfaces  for  specific  business  tasks.  Network  latency  is  then  less  of  an  issue  when  submitting 
one  large  request  instead  of  multiple  small  requests.  We  note  that  this  architecture  also  allows  the 
coarse-grained  service  to  execute  the  coarse  task  as  a  single  transaction  without  exposing  a 
transaction  object  to  the  client. 

Although  the  assumption  in  an  optimistic  system  is  that  transactions  will  succeed,  this  must  not 
be  taken  for  granted.  There  must  be  a  clearly  specified  method  of  notification  for  informing 
clients  when  an  optimistic  transaction  fails.  This  can  be  more  problematic  to  design  when 
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communications  between  the  client  and  server  are  truly  asynchronous.  The  client  must  retain  a 
record  of  all  pending  transactions  until  they  are  confirmed  by  the  server.  User  interface  design  is 
also  affected;  the  system  must  unobtrusive  user  feedback  about  the  state  of  transactions  as  well 
as  methods  for  recovering  work  from  failed  transactions,  so  that  the  user  does  not  have  to  re¬ 
enter  any  lost  data. 


Data  Integrity  for  CO  A  Sketch 

COA  Sketch/IOPC-X  is  dependent  on  the  current  IOPC-X  interface.  The  only  type  of  lock 
provided  is  an  exclusive  attribute  level  lock.  It  may  be  possible  with  a  significant  level  of  effort 
to  create  a  lock  management  system  based  on  these  locks.  However,  it  must  be  clearly 
understood  that  if  data  is  not  locked  before  it  is  read  from  the  database,  then,  without  exception, 
business  logic  may  be  operating  on  inconsistent  data.  For  example,  one  suggestion  for  limiting 
the  scope  of  locking  required  during  complex  operations  was  to  add  change  listeners  that  would 
monitor  the  COA  Sketch  JMS  change  notification  topic  for  changes  related  to  objects  in  use  by 
the  current  process.  This  design  would  not  eliminate  data  integrity  problems  -  it  would  simply 
limit  the  duration  of  the  race  condition  for  data  collisions. 

A  better  option  of  COA  Sketch/IOPC-X  would  be  to  explore  the  possibility  of  providing  a 
transaction  management  interface.  This  approach  would  necessarily  be  limited,  because  IOPC-X 
is  not  currently  being  actively  developed.  In  addition,  transaction  propagation  over  web  services 
is  difficult  and  error  prone.  COA  Sketch  would  need  to  access  the  transactional  IOPC-X  service 
using  RMI  instead  of  SOAP. 

COA  Sketch/aXiom  is  still  undergoing  design  and  has  greater  scope  for  change.  The  ideal  data 
integrity  solution  would  be  implementation  of  a  transaction  management  interface  using  the  Java 
Connector  Architecture  (JCA)  as  described  in  Section  0,  below. 


Rule/Knowledge-Based  Programming 

Rules-  or  Knowledge-based  programming  is  a  paradigm  where  objects  representing  facts  and 
rules  are  inserted  into  a  “Rules  Engine”.  The  rules  engine  applies  pattern-matching  techniques  to 
detennine  which  rules  apply  to  which  facts.  As  rules  are  matched,  they  are  executed  and  the 
consequences  of  their  execution  are  matched  iteratively  against  other  rules. 

Rules-oriented  programming  is  commonly  positioned  as  a  dynamic  solution.  In  theory,  business 
rules  can  be  written  or  altered,  tested  and  deployed  rapidly  in  order  to  change  the  behavior  of  a 
rules-based  system.  In  addition,  it  is  commonly  asserted  that  rules  provide  greater  transparency 
in  processing  by  virtue  of  their  terseness  and  declarative  nature.  However,  it  should  be  realized 
that  rule  development  is  still  programming,  albeit  at  a  level  closer  to  actual  business  operations. 
The  ability  to  develop  effective  rules  will  be  closely  related  to  the  expressive  power  of  the  data 
model  used  to  represent  facts  in  the  knowledge  base.  It  will  be  difficult  to  formulate  rules  to 
reason  over  an  overly  simplified  or  deeply  nested  data  model.  Also,  best  practices  indicate  that 
rules  should  be  atomic;  one  rule  should  apply  to  one  condition  and  have  one  consequence.  This 
means  that  rules  must  be  designed  to  work  together  in  compatible  sets.  Persons  who  are  not 
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subject  matter  experts  in  both  the  business  and  rule-development  domains  will  probably  have 
difficulty  writing  effective  rules. 


The  use  of  rules  and  rule  engines  do  provide  some  clear  benefits  in  dealing  with  complex 
problems.  The  rules  engine  assembles  facts  and  dependencies  for  rules.  This  provides  an 
inversion-of-control  (IoC)  system  for  the  procedural  code  in  rule  consequences  because 
dependencies  are  automatically  managed  by  the  engine.  The  concise,  declarative,  nature  of  rules 
in  conjunction  with  this  self-organizing  behavior  means  that  complex  constraint  problems  can 
often  be  expressed  and  solved  using  a  few  relatively  simple  rules. 


Data  Access  for  Rule-Based  Systems 

Generally,  rule  engines  and  other  inference  systems  are  assumed  to  have  access  to  all  the  data 
that  they  will  use  to  reason.  Conversely,  distributed  systems  must  make  explicit  calls  to  the  data 
store  in  order  to  retrieve  data.  For  complex  rule  sets,  it  may  not  always  be  clear  what  data  will  be 
required  to  execute  the  rules  until  run  time.  There  are  a  variety  of  issues  surrounding  this 
problem,  but  if  data  sets  do  need  to  be  retrieved  for  reasoning  in  conjunction  with  client  requests, 
it  is  vital  that  data  integrity  be  preserved.  Rule  engines  cannot  reason  over  in-memory  data  that 
may  be  concurrently  changing  in  the  data  store.  In  addition,  code  in  rule  consequences  may  need 
to  access  the  data  store  directly.  In  these  cases,  explicit  lock  management  is  particularly  awkward 
-  rules  are  designed  to  be  orthogonal  to  the  procedural  allocation  of  resources  such  as  locks.  A 
transaction  API  for  the  data  store  would  greatly  reduce  the  impact  of  these  problems. 

The  pattern-matching  nature  of  rules  drives  at  a  second  point-ontologies  are  generally  populated 
with  normalized,  object-oriented,  structures.  Conversely,  experience  with  SQL  data  stores  has 
shown  that  efficient  queries  often  require  a  somewhat  de-normalized  view  of  the  data.  This  need 
for  flattening  and  de-normalization  will  apply  to  the  representation  of  objects  in  both  the  data 
store  and  the  rule  engine  working  memory.  Based  on  this,  we  believe  that  ontology  data  model 
design  must  take  into  consideration  the  types  of  rules  and  queries  that  will  be  applied  as  well  as 
capturing  the  semantics  of  the  business  domain.  In  fact,  one  might  consider  designing  multiple 
ontological  representations  -  one  for  data  storage  and  access,  and  one  for  pure  business  object 
representations  -  ideally  with  a  well-defined  transformation  between  the  two. 


Data  Access  for  COA  Sketch 

COA  Sketch/IOPC-X’s  business  rules  system  has  several  fundamental  flaws  that  severely  limit 
its  capabilities  and  potential  for  expansion.  This  is,  in  part,  due  to  flaws  in  the  rules  and  rules 
engine  design.  However,  the  COA  Sketch  data  model  is  also  problematic. 


Data  Access  Issues 

The  COA  Sketch/IOPC-X  rules  engine  is  designed  to  make  a  single  pass  to  match  rules,  then  to 
execute  those  rules  sequentially.  Flaws  within  the  matcher  mean  some  data  is  missed  and  the 
two-pass  design  does  not  allow  reentrance,  so  the  code  that  can  be  executed  as  part  of  a  rule 
consequence  is  extremely  limited.  The  design  team  agrees  that  the  engine  implementation  needs 
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to  be  replaced.  However,  examining  the  code  for  the  individual  rules  points  to  some  problems  in 
the  CO  A  Sketch  data  model  as  well. 

Many  of  the  COA  Sketch  rules  deal  with  managing  timing  dependencies.  For  example,  when 
adding  a  new  object  that  has  a  time  object,  a  number  of  default  values  must  be  imported  from  the 
parent  object.  Accessing  the  parent  object’s  timing  information  is  painful,  because  the  rule  code 
may  have  to  work  its  way  up  the  object  tree  through  multiple  layers  of  indirection  and 
intennediary  objects  to  access  the  “real”  parent  object. 

Some  work  has  already  been  done  to  simplify  data  access  using  the  COA  Sketch  data  model,  but 
it  has  been  ad  hoc  and  a  full  review  of  the  data  model  and  web  service  interface  is  needed.  The 
initial  design  of  the  COA  Sketch  data  model  was  developed  before  the  COA  Sketch  client/server 
and  COA  Sketch/IOPC-X  interaction  use  cases  were  well  defined.  In  addition,  the  model 
definition  was  maintained  using  ontology  tools  and  code  generators.  As  a  consequence,  front-line 
developers  had  difficulty  updating  the  data  model  because  doing  so  required  altering  multiple 
schemas  in  multiple  locations  using  multiple  definition  languages.  This  inflexible  approach 
amplified  the  problems  of  the  initial  design  by  creating  a  major  incentive  to  “work  around”  data 
model  problems  rather  than  revisiting  the  design. 

The  model  for  date  and  timing  information  has  been  particularly  problematic.  The  data  model 
does  not  make  effective  use  of  inheritance  or  interfaces.  Instead,  multiple  attributes  representing 
various  offsets  and  base  times  are  publicly  exposed.  Defining  queries  and  matching  patterns  to 
work  with  these  structures  quickly  leads  to  heavily  nested  conditionals  that  are  difficult  to 
implement,  test  and  maintain.  In  addition,  the  schema  mixes  requirements  for  serialization  with 
data  representation,  leading  to  confusion  on  both  parts. 
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Recommendations 


Determining  the  best  way  ahead  for  COA  Sketch/IOPC-X  will  require  more  research.  It  is  highly 
recommended  that  an  end-to-end  review  of  COA  Sketch/IOPC-X  be  conducted  before  full-scale 
design  for  COA  Sketch/aXiom  begins.  At  a  minimum,  we  recommend  that  the  data  model  and 
particularly  the  date  and  constraint  model  be  reviewed  with  the  goal  of  expressing  queries  and 
pattern  matches  concisely.  We  believe  this  may  result  in  a  flatter,  more  redundant,  class  model 
with  fewer  classes  and  less  nesting  of  objects. 

Some  new  classes  may  need  to  be  added  to  express  some  system-level  concepts.  For  example, 
the  current  COA  Sketch/IOPC-X  use  cases  discuss  rules  for  handling  change  requests  according 
to  user-specific  preferences.  However,  the  data  model  does  not  define  any  classes  that  represent 
change  requests  or  users.  Adding  classes  such  as  deferred  promise  objects  that  can  act  as  handles 
to  concurrent  request,  change  objects  that  can  represent  user  requests  to  the  system  will  simplify 
the  syntax  required  for  implementing  these  use  cases. 

The  COA  Sketch/IOPC-X  Web  Service  Description  Language  (WSDL)  interface  will  need  to  be 
reviewed  at  the  same  time  as  the  data  model.  The  current  design  is  a  general  purpose  Create, 
Update,  Delete  model.  Some  work  is  on  going  to  add  higher-level  tasks  such  as  object  creation 
methods  for  specific  use  cases.  However,  system-level  study  is  needed  to  detennine  if  more 
business-level  tasks  can  be  defined  at  the  web  service  layer.  In  addition,  the  serialization 
constraints  inherent  in  the  current  data  model  need  to  be  removed.  Many  object  classes  cannot 
currently  be  serialized  as  stand-alone  objects  -  they  require  additional  document  portions.  This 
must  be  redesigned  so  that  the  data  model  objects  can  be  used  in  a  more  encapsulated  fashion. 

Finally,  the  IOPC-X  Results  and  discussions  identified  the  lack  of  support  for  ontological  data 
formats  (SPARQL  and  SPARQL  result-set  XML)  in  the  client  application  as  a  shortfall. 
Admittedly,  the  data  interchange  between  the  COA  Sketch/IOPC-X  client  and  server  was 
problematic.  However,  pushing  the  responsibility  for  query  execution  and  processing  up  to  the 
client  tier  goes  against  the  theory  of  N-tiered  architectural  design  and  violates  the  assumption  of 
a  course-grained,  optimistic  system  described  in  Section  0  above.  Obviously,  expectations  for  the 
capabilities  of  an  ontological  data  access  client  must  be  recalibrated  and  agreed  upon.  One  might 
well  consider  the  COA  Sketch  service  the  true  ontological  client  and  the  COA  Sketch  thin  client 
merely  a  display  layer.  In  any  case,  SPARQL  result  sets  are  not  ideal  for  passing  data  in  a  client  / 
server  system.  Other  ontological  technologies  such  as  RDF/XML  may  be  more  suitable,  but 
replacing  a  well -know  and  understood  technology  like  WSDL  with  RDF/XML  requires  much 
more  research  before  a  decision  should  be  made  to  pursue  this  design  path. 


Integration  with  J2EE  Applications 

The  Java  2  Enterprise  Edition  (J2EE)  framework  was  designed  for  accessing  transactional  data 
stores.  Obviously,  the  most  common  type  of  data  store  is  a  Structured  Query  Language  (SQL) 
Relational  Database  Management  System  (RDBMS).  However,  there  are  specific  previsions  for 
non-SQL  data  sources.  The  Java  Connector  Architecture  (JCA)  shown  in  Figure  1  is  designed  to 
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provide  a  point  of  integration  for  any  transactional  data  store  or  Enterprise  Information  System 
(EIS). 


Figure  1:  The  Java  Connector  Architecture  for  integrating  external  Enterprise 
Information  Systems  with  J2EE  application  servers. 

A  JCA  resource  adapter  implements  three  main  interfaces  for  data  access: 

•  Authentication  and  authorization  for  the  data  store  are  provided  through  the  Java 
Authentication  and  Authorization  Service  (JAAS)  interface. 

•  Connection  management  is  provided  through  the  Common  Client  Interface  (CCI). 

•  Transaction  management  is  provided  through  the  Java  Transaction  API  (JTA). 

The  J2EE  application  server  is  designed  to  use  these  interfaces  to  provide  managed  connections 
and  transactions  to  client  applications.  It  is  possible  to  communicate  with  external  data  sources 
without  using  a  JCA  resource  adapter.  However,  by  implementing  the  JCA  resource  adapter 
interface,  a  data  store  works  with  the  J2EE  architecture  rather  than  against  it.  J2EE  objects  have 
highly  specific  lifecycles  and  management  constraints.  Only  resource  adapter  objects  have  the 
lifecycle  and  coding  constraints  to  be  truly  suitable  for  implementing  an  adapter  to  an  external 
data  store. 

Data  integrity  must  be  part  of  the  design  of  a  distributed  knowledge  system.  Providing  a  data 
store  that  supports  transactions  and  two-phase  commits  is  the  least  burdensome  approach  and  has 
the  most  potential  for  integrating  into  complex  systems. 

The  Java  Connector  Architecture  is  designed  specifically  for  the  purpose  of  providing  access  to 
arbitrary  data  stores.  It  provides  three  well-known  interface  contracts  for  security,  transactions 
and  connection  management  with  which  client  developers  are  already  familiar.  Ontological  data 
sources  should  be  accessed  through  JCA  resource  adapters.  This  will  facilitate  clean  and  flexible 
designs  for  client  applications. 
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The  semantics  of  ontologies  in  the  data  store  and  rule  engine  working  memory  take  into  account 
the  rules  and  queries  they  are  designed  to  support.  This  may  lead  to  a  de-no nnalized,  less  object- 
oriented,  design  than  ontology  theory  might  suggest. 
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Abbreviations,  Acronyms,  Trademarks  &  Copyrights 


ABAC 

Attribute  Based  Access  Control 

ACE 

Advanced  Collaborative  Environments 

AFRL 

Air  Force  Research  Laboratory 

AOC 

Air  and  Space  Operations  Center 

API 

Application  Programming  Interface 

AS 

Attribute  Service 

ASAP 

Asynchronous  Service  Access  Protocol 

ATM 

Asynchronous  Transfer  Mode 

AVDL 

Application  Vulnerability  Description  Language 

BPEL 

Business  Process  Execution  Language 

BSP 

Basic  Security  Profile 

CES 

Core  Enterprise  Services 

CGS-WG 

CIM  based  Grid  Schema  WG 

CM 

Capability  Module 

COA 

Course  of  Action 

COCOM 

Combatant  Command 

COI 

Community-of-Interest 

CORBA 

Common  Object  Request  Broker  Architecture 

CORE 

Controlled  Requirements  Expression 

CoreTax 

Core  Taxonomy 

COTS 

Commercial  Off-The-Shelf 

CPIM 

Common  Presence  and  Instant  Messaging 

CSS 

Cascading  Style  Sheets 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DB 

Database 

DDMS 

Department  of  Defense  Discovery  Metadata  Specification 

DECC 

Defense  Enterprise  Computing  Centers 

DiffServ 

Differential  Services 

DISR 

DoD  IT  Standards  Registry 

DoD 

Department  of  Defense 

DODAF 

Department  of  Defense  Architecture  Framework 

DoDISS 

Department  of  Defense  Intelligence  Infonnation  System 

DOM 

Document  Object  Model 

DSS 

Digital  Signature  Services 

ECB 

Early  Capabilities  Baseline 

_i  1  M 

EJB 

Enterprise  JavaBeans 

FTP 

File  Transfer  Protocol 

GFE 

Government  Furnished  Equipment 

GGF 

Global  Grid  Forum 

GIG 

Global  Information  Grid 

GOC-CE 

Global  Operations  Center  -  Collaborative  Environment 

GOTS 

Government  Off-The-Shelf 

GUI 

Graphical  User  Interface 

D-33 


GUID 

Globally  Unique  ID 

HAIPE 

High  Assurance  Internet  Protocol  Encryptor 

HCI 

Human  Computer  Interface 

HPW 

Human  Performance  Wing 

HTML 

Hypertext  Markup  Language 

HTTP 

Hypertext  Transfer  Protocol 

IA 

Infonnation  Assurance 

IAW 

In  Accordance  With 

IC 

Intelligence  Community 

ICMPv6 

Internet  Control  Message  Protocol  Version  6 

ID-FF 

Identity  Federation  Framework 

ID-SIS 

Identity  Services  Interface  Specifications 

ID-WSF 

Identity  Web  Services  Framework 

IETF 

Internet  Engineering  Task  Force 

IMP 

Instant  Messaging  and  Presence 

IMPP 

Instant  Messaging  and  Presence  Protocol 

Tnfoset 

Infonnation  Set 

10 

Infonnation  Operations 

I0PC 

Infonnation  Operations  Planning  Capability 

IOPC-X 

Infonnation  Operations  Planning  Capability  -  Experiment 

IP 

Internet  Protocol 

IPT 
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IPTEL 

IP  Telephony 

IPTO 

Infonnation  Processing  Technology  Office 

IPv6 

Internet  Protocol  Version  6 

IRI 

Internationalized  Resource  Identifiers 

ISM 

Infonnation  Security  Markings 

IT 

Infonnation  Technology 

IWPC 

Infonnation  Warfare  Planning  Capability 

J2EE'" 

Java  2  Enterprise  Edition 

J7 

Engineering  Staff  Section 

JAAS 

.  1 M 

Java  Authentication  and  Authorization  Service 

JDBC'” 

Java  Database  Connectivity 

JDK'” 

•  1 M 

Java  Development  Kit 

JEFX 

Joint  Effects  Force  Experiment 

JFCOM 

Joint  Forces  Command 

JMS 

1 M 

Java  Message  Service 

JNDI 

Java  Naming  and  Directory  Interface 

JTT 

Joint  Targeting  Toolkit 

JVM'" 

Java  Virtual  Machine 

JWS 

i  im 

Java  Web  Start 

KOS 

Knowledge  Organization  Systems 

KPP 

Key  Perfonnance  Parameter 

LDAP 

Lightweight  Directory  Access  Protocol 

MDB 

Message  Driven  Bean 
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MIB 

Management  Information  Base 

MIDB 

Militarized  Intelligence  Database 

MIPv6 

Mobility  for  IPv6 

MLS 

Multilevel  Security 

MWG 

Metadata  Working  Group 

NCE 

Net  Control  Element 

NCES 

Net-Centric  Core  Enterprise  Services 

NCOW-RM 

Net-Centric  Operational  Warfare  Reference  Model 

NECC 

Net-Enabled  Command  Capability 

NIP 

National  Implementation  Plan 

NS  A 

National  Security  Agency 

OASIS 

Organization  for  the  Advancement  of  Structured  Information 
Standards 

OGSA 

Open  Grid  Services  Architecture 

OGSI 

Open  Grid  Services  Infrastructure 

OSGi 

Open  Services  Gateway  Initiative 

OWL 

Web  Ontology  Language 

PDS 

Policy  Decision  Service 

PDP 

Policy  Decision  Point 

PEP 

Policy  Enforcement  Point 

PKI 

Public  Key  Infrastructure 

PPP 

Point-to-Point  Protocol 

PRS 

Policy  Retrieval  Service 

PSTN 

Public  Switched  Telephone  Network 

RCP 

Rich  Client  Platform 

RCVS 

Robust  Certificate  Validation  Services 

RDF 

Resource  Description  Framework 

RDF-S 

Resource  Descriptoin  Framework  Schema 

REST 

Representational  State 

RFC 

Request  For  Comments 

RH 

Human  Effectiveness  Directorate 

RMI 

Remote  Method  Invocation 

RSVP 

ReSerVation  Protocol 

SAML 

Security  Assertion  Markup  Language 

SAPIENT 
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SDK 

Software  Development  Kit 

SIGTRAN 

Signaling  Transport 

SIMPLE 

SIP  for  Instant  Messaging  and  Presence  Leveraging 

Extensions 

SIP 

Session  Initiation  Protocol 

SIPPING 

SIP  Project  Investigation 

SIT 

Simple  Internet  Transition 

SKOS 

Simple  Knowledge  Organization  System 

SMIL 

Synchronized  Multimedia  Integration  Language 

SMTP 

Simple  Mail  Transfer  Protocol 
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SOA 

Service  Oriented  Architecture 

SOAP 

Simple  Object  Access  Protocol 

SPARQL 

Protocol  and  RDF  Query  Language 

SVG 

Scalable  Vector  Graphics 

SPVT 

Strategy  Planning  Visualization  Tool 

STINFO 

Scientific  and  Technical  Information 

SWT 

Standard  Widget  Toolkit 

TAG 

Technical  Architecture  Group 

TBMCS 

Theatre  Battle  Management  Core  System 

TC 

Technical  Committee 

TSP 

Time  Sensitive  Planning 

UDDI 

Universal  Description,  Discovery,  and  Integration 

UI 

User  Interface 

UML 

Unified  Modeling  Language 

URI 

Uniform  Resource  Identifier 

URL 

Uniform  Resourse  Locator 

USERID 

User  Identification 

VisIOn 

Virtual  Integrated  Support  for  the  Information  Operations 
Environment 

VoIP 

Voice  Over  IP 

VPIM 

Voice  Profile  for  Internet  Mail 

W3C 

World  Wide  Web  Consortium 

WAS 

Web  Application  Security 

WG 

Working  Groups 

ws 

Web  Services 

WSDL 

Web  Services  Definition  Language 

WS-I 

Web  Services-Interoperability 

WS-I18N 

Web  Services-Internationalization 

ws-s 

Web  Services-Security 

wso 

Web  Services  Orchestration 

WSRF 

Web  Services  Resource  Framework 

WSRF-BF 

WS-BaseFaults 

WSRF-RL 

WS-ResourceLifetime 

WSRF-RP 

WS-ResourceProperties 

WSRF-SG 

WS-ServiceGroup 

WSRP 

WS  Remote  Portlet 

WSS 

Web  Services  Security 

XACML 

Extensible  Access  Control  Markup  Language 

XCBF 

XML  Common  Biometric  Fonnat 

XHTML 

Extensible  Hypertext  Markup  Language 

XLIFF 

XML  Localization  Interchange  File  Fonnat 

XMI 

XML  Metadata  Interchange 

XML 

extensible  Markup  Language 

XMPP 

XML  Messaging  and  Presence  Protocol 

XSD 

XML  Schema  Definition 
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XSL 

extensible  Stylesheet  Language 

XSLT 

Extensible  Stylesheet  Language  Transfonnation 

API 

Application  Programming  Interface 

CM 

Capability  Modules 

EJB 

Enterprise  Java  Bean 

IC 

Intelligence  Community 

IOPC-X 

Infonnation  Operations  Planning  Capability  -  Experiment 

ISM 

Information  Security  Markings 

IWPC 

Information  Warfare  Planning  Capability 

JDBC 

Java  Database  Connectivity 

JPA 

Java  Persistence  API 

JPQL 

Java  Persistence  Query  Language 

OV 

Operational  View 

OWL 

Web  Ontology  Language 

SQL 

Structured  Query  Language 

SV 

Systems  View 

XML 

extensible  Markup  Language 

XSD 

XML  Schema  Definition 
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